Re: Compiling Cyrus IMAPD on AMD Opteron
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]
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: 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? Because of either: 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it shouldn't be (libraries) 2. Compiler bugs. Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. I don't think the Cyrus build uses --shared, but I didn't check. ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote: On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: 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? Because of either: 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it shouldn't be (libraries) 2. Compiler bugs. Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. I don't think the Cyrus build uses --shared, but I didn't check. ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Compiling Cyrus IMAPD on AMD Opteron
Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) From: Rob Siemborski [EMAIL PROTECTED] Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. Yeah, Solaris is one of the platforms that is tolerant of mixing non -fPIC into shared libraries. It poses a large memory hit (shared libraries with non -fPIC code aren't shared between processes). The major problem with trying to add -fPIC to the distribution is that isn't how it works on all compilers and all OS's. Thus the pain that is libtool. I've thought about making all of Cyrus build with libtool, and then I read some of the bug reports we get because of libsasl's use of libtool and start thinking better of it. I wonder if we could write a configure test to determine if this is necessary on a given platform. To do it in all generality requires duplicating libtool. Larry
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Rob Siemborski wrote: On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. I stand corrected. ;) All this trouble of building static libsasl led me to think this way. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. It depends on how perl is built and possibly type of compiler/linker flags used. Also, CFLAGS=-fPIC breaks 'make depend'. I am not sure what is the best way to deal with this, fix makedepend?. -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Lawrence Greenfield wrote: Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) From: Rob Siemborski [EMAIL PROTECTED] Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. Yeah, Solaris is one of the platforms that is tolerant of mixing non -fPIC into shared libraries. It poses a large memory hit (shared libraries with non -fPIC code aren't shared between processes). -zcombreloc linker flag make my installation require -fPIC. The major problem with trying to add -fPIC to the distribution is that isn't how it works on all compilers and all OS's. Thus the pain that is libtool. I've thought about making all of Cyrus build with libtool, and then I read some of the bug reports we get because of libsasl's use of libtool and start thinking better of it. I wonder if we could write a configure test to determine if this is necessary on a given platform. To do it in all generality requires duplicating libtool. Larry -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On 13 Jun 2003, Rob Siemborski said: On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. Isn't that what libtool is for? For the Perl stuff explicitly: [EMAIL PROTECTED]:46$ perl -V:cccdlflags cccdlflags='-fpic'; [EMAIL PROTECTED]:47$ -- Stephen L. Ulmer [EMAIL PROTECTED] Senior Systems Programmer http://www.ulmer.org/ Northeast Regional Data Center VOX: (352) 392-2061 University of Florida FAX: (352) 392-9440
Compiling Cyrus IMAPD on AMD Opteron
I have a dual AMD Opteron configured with the SUSE Linux 8 for AMD64. I am testing the trail system out. The problem comes in when the make gets to compiling the Perl IMAP module. Cyrus SASL compiled fine. GCC: gcc version 3.2.2 (SuSE Linux) Perl ver: 5.8.0 Cyrus SASL ver: 2.1.13 ./configure --with-openssl --enable-gssapi --enable-plain Cyrus IMAPD ver: 2.1.13 ./configure --with-openssl --with-dbdir --with-sasl --with-libwrap --without-ucdsnmp [snippet] 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. Curtis Robinson crobinso.at.fit.edu
Re: Compiling Cyrus IMAPD on AMD Opteron
Unfortunately, you've snipped the part that would show what's really broken: the compilation of libcyrus.a. It looks like Perl on that system is misconfigured, and didn't compile libcyrus.a with the -fPIC option needed to link it into a shared library. [EMAIL PROTECTED] wrote: I have a dual AMD Opteron configured with the SUSE Linux 8 for AMD64. I am testing the trail system out. The problem comes in when the make gets to compiling the Perl IMAP module. Cyrus SASL compiled fine. GCC: gcc version 3.2.2 (SuSE Linux) Perl ver: 5.8.0 Cyrus SASL ver: 2.1.13 ./configure --with-openssl --enable-gssapi --enable-plain Cyrus IMAPD ver: 2.1.13 ./configure --with-openssl --with-dbdir --with-sasl --with-libwrap --without-ucdsnmp [snippet] 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. Curtis Robinson crobinso.at.fit.edu
Re: Compiling Cyrus IMAPD on AMD Opteron
[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
