Relocation errors - "recompile with -fPIC"

[Steve Hay]

Attempts to build mod_perl with some versions of perl (5.18.4, 5.22.0)
on some OSes (Debian/wheezy, FreeBSD 9.2) have generated linker errors
like this:

/usr/bin/ld: /opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a(op.o):
relocation R_X86_64_32S against `PL_sv_yes' can not be used when
making a shared object; recompile with -fPIC
/opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a: could not
read symbols: Bad value

/usr/bin/ld: /usr/perl5.22.0t/lib/5.22.0/amd64-freebsd-thread-multi/CORE/libperl.a(op.o):
relocation R_X86_64_32 against `PL_op_mutex' can not be used when
making a shared object; recompile with -fPIC
/usr/perl5.22.0t/lib/5.22.0/amd64-freebsd-thread-multi/CORE/libperl.a:
could not read symbols: Bad value

Many other users with various versions of perl and various OSes report
successful builds, so there is something specific about a few setups
that is not working, but I do not understand what these errors mean.

Is anyone here able to shed some light on what sort of thing the
problems might be?

[H.Merijn Brand]

I got no answer whatsoever on this mail:

http://www.nntp.perl.org/group/perl.perl5.porters/2014/12/msg223919.html

From: H.Merijn Brand
Date: December 24, 2014 20:28
Subject: -fPIC not passed to compilation
Message ID: 20141224212...@pc09.procura.nl

I have 5.20.1

This is perl 5, version 20, subversion 1 (v5.20.1) built for x86_64-linux-thread-multi-ld

$ perl -V:cccdlflags
cccdlflags='-fPIC';

but

$ make op.o
cc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings op.c

resulting in errors like

make[1]: Entering directory '/pro/3gl/hexchat-git/plugins/perl'
CC perl_la-perl.lo
CCLD perl.la
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /pro/lib/perl5/5.20.1/x86_64-linux-thread-multi-ld/CORE/libperl.a(op.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/pro/lib/perl5/5.20.1/x86_64-linux-thread-multi-ld/CORE/libperl.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:471: recipe for target 'perl.la' failed
make[1]: *** [perl.la] Error 1
make[1]: Leaving directory '/pro/3gl/hexchat-git/plugins/perl'
Makefile:400: recipe for target 'all' failed

when used in other software

Why is -fPIC not passed to CC?


--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

[Leon Timmermans]

Have those perls been compiled with useshrplib?

Leon

[Andy Dougherty]

On Thu, Jun 04, 2015 at 11:43:32AM +0200, H.Merijn Brand wrote:
> On Thu, 4 Jun 2015 09:17:31 +0100, Steve Hay
> <steve...@googlemail.com> wrote:
>
> > Attempts to build mod_perl with some versions of perl (5.18.4, 5.22.0)
> > on some OSes (Debian/wheezy, FreeBSD 9.2) have generated linker errors
> > like this:
> >
> > /usr/bin/ld: /opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a(op.o):
> > relocation R_X86_64_32S against `PL_sv_yes' can not be used when
> > making a shared object; recompile with -fPIC
> > /opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a: could not
> > read symbols: Bad value
> >

It used to be the case that -fPIC came with a significant performance
penalty. (There's a note in INSTALL dating back to 1996 about a 15%
penalty on my Solaris 2.5/i686 test system.) Thus the default was to build
without -fPIC, but if you anticipated wanting to link to other stuff (e.g.
mod_perl) you were encouraged to select -Duseshrplib. If someone wants to
do some more up-to-date testing, I could certainly see changing the default
(while still allowing -Uuseshrplib).

--
Andy Dougherty doug...@lafayette.edu

[Steve Hay]

So assuming that the perls in question (having the mod_perl build
problems) have been built with -Duseshrplib, what does mod_perl, or
the person trying to build mod_perl, need to do with regard to the
-fPIC flag to get the build to work?

I'm not clear whether this is something that mod_perl needs to address
(e.g. in its Makefile.PL), or if there is some action that the user
needs to take to build mod_perl with such a perl.

[H.Merijn Brand]

On Thu, 4 Jun 2015 14:10:33 +0100, Steve Hay

*I* never use -Duseshrplib, but I *do* use libperl.so to be used in
useful stuff like hexchat plugins.

[Andy Dougherty]

On Thu, Jun 04, 2015 at 02:10:33PM +0100, Steve Hay wrote:
> On 4 June 2015 at 12:58, Andy Dougherty <doug...@lafayette.edu> wrote:
> > On Thu, Jun 04, 2015 at 11:43:32AM +0200, H.Merijn Brand wrote:
> >> On Thu, 4 Jun 2015 09:17:31 +0100, Steve Hay
> >> <steve...@googlemail.com> wrote:
> >>
> >> > Attempts to build mod_perl with some versions of perl (5.18.4, 5.22.0)
> >> > on some OSes (Debian/wheezy, FreeBSD 9.2) have generated linker errors
> >> > like this:
> >> >
> >> > /usr/bin/ld: /opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a(op.o):
> >> > relocation R_X86_64_32S against `PL_sv_yes' can not be used when
> >> > making a shared object; recompile with -fPIC
> >> > /opt/perl-5.18.4/lib/5.18.4/x86_64-linux/CORE/libperl.a: could not
> >> > read symbols: Bad value

[. . . ]

> So assuming that the perls in question (having the mod_perl build
> problems) have been built with -Duseshrplib, what does mod_perl, or
> the person trying to build mod_perl, need to do with regard to the
> -fPIC flag to get the build to work?

I don't think that's a correct assumption. Note that they are trying to link
against /opt/perl-5.18.4/.../libperl.a. If they had built with -Duseshprlib,
that library wouldn't exist, and they would be linking against libperl.so.

> I'm not clear whether this is something that mod_perl needs to address
> (e.g. in its Makefile.PL), or if there is some action that the user
> needs to take to build mod_perl with such a perl.

I think the user needs to rebuild perl with -Duseshrplib.

--
Andy Dougherty doug...@lafayette.edu

[Petr Pisar]

Exactyl. mod_perl is a dynamic library loaded by httpd. Therefore all
the code in the mod_perl must be position indepent. Including perl
interpreter.

The error message was about an attempt to link a static perl interpreter
(libperl.a) into mod_perl when creating final dynamic library.

Perl build process creates either dynamic executable (libperl.so), or
static one (libperl.a). Not both of them. In order to have libperl.so,
one needs to configure perl with -Duseshrplib.

-- Petr

[H.Merijn Brand]

Like this :( - Now I have to start all over again. From scratch :(

make[4]: Entering directory '/pro/3gl/hexchat-git/plugins/perl'
CC perl_la-perl.lo
CCLD perl.la
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /pro/lib/perl5/5.22.0/x86_64-linux-thread-multi-ld/CORE/libperl.a(op.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/pro/lib/perl5/5.22.0/x86_64-linux-thread-multi-ld/CORE/libperl.a: error adding symbols: Bad value

collect2: error: ld returned 1 exit status

Makefile:476: recipe for target 'perl.la' failed
make[4]: *** [perl.la] Error 1
make[4]: Leaving directory '/pro/3gl/hexchat-git/plugins/perl'
Makefile:405: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/pro/3gl/hexchat-git/plugins/perl'
Makefile:426: recipe for target 'all-recursive' failed

[Steve Hay]

Ok, thanks to all for the help. I will pass this information on and
hopefully it will resolve the problem.