Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c
Why does -fPIC fix this problem? > [EMAIL PROTECTED] wrote: > >>make[2]: Entering directory `/root/src/cyrus-imapd-2.1.13/perl/imap' >>rm -f blib/arch/auto/Cyrus/IMAP/IMAP.so >>LD_RUN_PATH="/usr/lib64" cc -shared -L/usr/local/lib64 IMAP.o -o >>blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a -lssl -lcrypto >>/usr/lib64/gcc-lib/x86_64-suse-linux/3.2.2/../../../../x86_64-suse-linux/bin/ld: >>../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used >>when making a shared object; recompile with -fPIC >>../../lib/libcyrus.a: could not read symbols: Bad value >>collect2: ld returned 1 exit status >>make[2]: *** [blib/arch/auto/Cyrus/IMAP/IMAP.so] Error 1 >>make[2]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl/imap' >>make[1]: *** [all] Error 1 >>make[1]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl' >>make: *** [all] Error 1 >>[snippet] >> >>Can anyone help me with it? I wanted to get it working to test out the >>performance of the system. >> >> > What you need to look at is where imclient.c was compiled. Either it > wasn't compiled with -shared, or the gcc port is not properly choosing > the right flags for -shared. Run the cc command yourself in that > directory, adding the -v flag and see if -fPIC gets passed to cc1. If > not, you can fix the problem just by adding -fPIC yourself in the > compile commands. If it is getting passed, then it looks like the > machine definition is improperly choosing a particular addressing mode > when generating PIC code and that will need to get fixed by whoever > maintains the x86_64 machine description for gcc. > > -- > John A. Tamplin Unix System Administrator > Emory University, School of Public Health +1 404/727-9931 > > > --- Curtis Robinson [EMAIL PROTECTED]
