static libperl?

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>

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 making a 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

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 making a 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&amp;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 making a 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&amp;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 making a 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