Thread: static libperl?
Earlier today I noticed these lines in this buildfarm log http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-08-16%2002:05:00 ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -fPIC -DPIC -shared-Wl,-x,-soname,libplperl.so.0 plperl.o spi_internal.o SPI.o -L/usr/local/lib -L/usr/local/lib/perl5/5.6.1/mach/CORE-L../../../src/port -L/usr/local/lib -Wl,-E /usr/local/lib/perl5/5.6.1/mach/auto/DynaLoader/DynaLoader.a-lperl -lm -lc -lcrypt -lutil -Wl,-R/usr/local/lib/perl5/5.6.1/mach/CORE-o libplperl.so.0 /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when makinga shared object; recompile with -fPIC /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a: could not read symbols: Bad value Does that mean that we are attempting to link against a static libperl.a? I thought we were supposed to inhibit that. Or am I misreading? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when makinga shared object; recompile with -fPIC > Does that mean that we are attempting to link against a static libperl.a? > I thought we were supposed to inhibit that. Platypus is freebsd though, and we now think we don't need shared libraries on that platform: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/makefiles/Makefile.freebsd.diff?r1=1.19;r2=1.20 I am wondering if the issue is that you need -fPIC and libperl was only made with -fpic. It could be that platypus was only passing before because it didn't try to build plperl. regards, tom lane
Andrew Dunstan wrote: > > Earlier today I noticed these lines in this buildfarm log > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-08-16%2002:05:00 > > > ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wendif-labels -fno-strict-aliasing -g -fPIC -DPIC -shared > -Wl,-x,-soname,libplperl.so.0 plperl.o spi_internal.o SPI.o > -L/usr/local/lib -L/usr/local/lib/perl5/5.6.1/mach/CORE > -L../../../src/port -L/usr/local/lib -Wl,-E > /usr/local/lib/perl5/5.6.1/mach/auto/DynaLoader/DynaLoader.a -lperl -lm > -lc -lcrypt -lutil -Wl,-R/usr/local/lib/perl5/5.6.1/mach/CORE -o > libplperl.so.0 > /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): > relocation R_X86_64_32S can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a: could not read symbols: > Bad value > > > Does that mean that we are attempting to link against a static > libperl.a? I thought we were supposed to inhibit that. That error definitely comes from trying to link code that's not built with -fPIC, usually what's found in static archives, into a shared object. IIRC, the PostgreSQL configure scripts and Makefiles directly query Perl for the right options, e.g. cccdlflags, to pass to the compiler and linker to link with libperl. How is Perl built on this FreeBSD box? Is it from the ports collection or is it a vanilla build? I think the ports collection ensures that "-Duseshrplib"is passed to the Perl Configure script to force a shared libperl to be built. Cheers, -- Johnny Lam <jlam@NetBSD.org>
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>/usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when makinga shared object; recompile with -fPIC >> >> > > > >>Does that mean that we are attempting to link against a static libperl.a? >>I thought we were supposed to inhibit that. >> >> > >Platypus is freebsd though, and we now think we don't need shared >libraries on that platform: >http://developer.postgresql.org/cvsweb.cgi/pgsql/src/makefiles/Makefile.freebsd.diff?r1=1.19;r2=1.20 > >I am wondering if the issue is that you need -fPIC and libperl was only >made with -fpic. > >It could be that platypus was only passing before because it didn't try >to build plperl. > > > > Yeah. I thought we didn't want to link large static libraries into the backend, regardless of other issues, but I guess I should have read the makefile more closely. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Earlier today I noticed these lines in this buildfarm log > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-08-16%2002:05:00 > /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when makinga shared object; recompile with -fPIC > /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a: could not read symbols: Bad value I've fixed Makefile.freebsd to assert allow_nonpic_in_shlib only on i386; that should solve the above problem (by keeping platypus from trying to build plperl :-(). It may be there are some other architectures we can safely set allow_nonpic_in_shlib for, but I don't know exactly which. regards, tom lane
On Wed, Aug 24, 2005 at 04:24:10PM -0400, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Earlier today I noticed these lines in this buildfarm log > > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-08-16%2002:05:00 > > > /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when makinga shared object; recompile with -fPIC > > /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a: could not read symbols: Bad value > > I've fixed Makefile.freebsd to assert allow_nonpic_in_shlib only on > i386; that should solve the above problem (by keeping platypus from > trying to build plperl :-(). It may be there are some other > architectures we can safely set allow_nonpic_in_shlib for, but I don't > know exactly which. Note that platypus is still configured to build plperl... ISTM that if it's unable to do so we should throw some kind of error, prefferably at configure time. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461