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 <[EMAIL PROTECTED]>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to