Compiling Cyrus IMAPD on AMD Opteron

[curtis at oushi.org]

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?

> curtis at oushi.org 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
crobinso at fit.edu