linker error with new linker

linker error with new linker

[John Calcote]

Hi all -- 
 
I've run into a problem with a late version of the GNU linker (ld) that
wasn't there in previous versions. I now get the following error on my
project openslp:
 
gcc -shared [...] .libs/libslp_reg.o 
-Wl,--whole-archive ../common/.libs/libcommonlibslp.a 
-Wl,--no-whole-archive -lm -lpthread -lnsl -lresolv -Wl,-soname 
-Wl,libslp.so.1 -o .libs/libslp.so.1.0.0
[...] x86_64-suse-linux/bin/ld: 
../common/.libs/libcommonlibslp.a(slp_atomic.o): relocation R_X86_64_32

against `a local symbol' can not be used when making a shared object; 
recompile with -fPIC
 
I think I know what's happening here. We're building a shared library
from a set of static libraries. The static libraries were built with GNU
autotools configure script and makefiles automatically. We're just
reusing those "convenience" libraries to build our ultimate target - a
shared library. I don't know why the linker allowed this in the past,
but it now appears to care that the original static libraries that we're
linking into the shared object were NOT built with the -fPIC flag
(naturally - they're STATIC libraries).
 
If this assumption is correct, then I believe it's really a good thing
- we SHOULD use all -fPIC flagged code in shared libraries. But I'm not
sure why it's become important in this later version of the linker.
 
SuSE Linux 10 box - ld is 2.16.91.0.2 20050720 (packaged with gcc
4.0.2): works fine.
 
SuSE Enterprise Linux 10 Beta 8 - ld is newer (whatever SuSE's
packaging along with gcc 4.1.0-5): generates the above error. 
Here's my problem. Convenience libraries are good. They allow us to
break large sets of files up into smaller sets of objects (static
libraries) that we can deal with from one build directory to another. I
can reference a static library later in my build easily from another
directory. This is fairly common practice, I believe. With the advent of
this new linker error, what can I do to maintain this model? I don't
ship the static convenience libraries as part of my package. They just
make the build system a bit more modular. Is there a recommended
approach to fixing this issue without reorganizing my entire automake
system? 
 
For now, I going to try to override the static library flags LDFLAGS
for the convenience libraries and force the -fPIC flag on, which should
work fine since I don't expect consumers to use these convenience
libraries. But if there's a better way, please let me know.
 
Thanks in advance,
John Calcote
Novell, Inc

Re: linker error with new linker

[Daniel Jacobowitz]

On Tue, Jul 11, 2006 at 11:08:12PM -0600, John Calcote wrote:
> If this assumption is correct, then I believe it's really a good thing
> - we SHOULD use all -fPIC flagged code in shared libraries. But I'm not
> sure why it's become important in this later version of the linker.

It has never worked fine, esp. on x86_64.  It's just the linker wasn't
as rigorous about telling you about the problem previously.

> SuSE Enterprise Linux 10 Beta 8 - ld is newer (whatever SuSE's
> packaging along with gcc 4.1.0-5): generates the above error. 
> Here's my problem. Convenience libraries are good. They allow us to
> break large sets of files up into smaller sets of objects (static
> libraries) that we can deal with from one build directory to another. I
> can reference a static library later in my build easily from another
> directory. This is fairly common practice, I believe. With the advent of
> this new linker error, what can I do to maintain this model? I don't
> ship the static convenience libraries as part of my package. They just
> make the build system a bit more modular. Is there a recommended
> approach to fixing this issue without reorganizing my entire automake
> system? 
>  
> For now, I going to try to override the static library flags LDFLAGS
> for the convenience libraries and force the -fPIC flag on, which should
> work fine since I don't expect consumers to use these convenience
> libraries. But if there's a better way, please let me know.

LDFLAGS has nothing to do with it - you don't link archives.  Compile
all code that is destined to end up in a shared library with -fPIC (in
CFLAGS).

-- 
Daniel Jacobowitz
CodeSourcery

Re: linker error with new linker

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

"John Calcote" <jcalcote@novell.com> writes:

> [...]
> If this assumption is correct, then I believe it's really a good thing
> - we SHOULD use all -fPIC flagged code in shared libraries. But I'm not
> sure why it's become important in this later version of the linker.
>  
> SuSE Linux 10 box - ld is 2.16.91.0.2 20050720 (packaged with gcc
> 4.0.2): works fine.
> [...]

It was always this way on x86-64 - and ia64, s390, ppc.  Just i386
handles shared libs without -fPIC - and even there it's not
recommended.  

It just might be that GCC generated different code than before so that
you now have a relocation where you had a different one before.

Cheers,
Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: linker error with new linker

[İsmail Dönmez]

Çarşamba 12 Temmuz 2006 18:31 tarihinde, Andreas Jaeger şunları yazmıştı: 
> "John Calcote" <jcalcote@novell.com> writes:
> > [...]
> > If this assumption is correct, then I believe it's really a good thing
> > - we SHOULD use all -fPIC flagged code in shared libraries. But I'm not
> > sure why it's become important in this later version of the linker.
> >
> > SuSE Linux 10 box - ld is 2.16.91.0.2 20050720 (packaged with gcc
> > 4.0.2): works fine.
> > [...]
>
> It was always this way on x86-64 - and ia64, s390, ppc.  Just i386
> handles shared libs without -fPIC - and even there it's not
> recommended.

I always thought this was a gcc bug but I guess its not and its the intended 
behaviour ?

Regards,
ismail

-- 
日本のanimeは揺れる 

Re: linker error with new linker

[John Calcote]

Deigo,

Thank you! 

This was exactly what I was looking for. I had already considered the idea of adding -fPIC to my CFLAGS for the static libraries, but immediately threw that out as a "hack". ;-)
 
John

>>> Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> 7/12/2006 10:45 AM >>>
On Wednesday 12 July 2006 18:27, John Calcote wrote:
> However, the real question was: Does anyone know if there's a
> "standard" way of dealing with the "linking shared libraries from static
> libraries in autotools" issue?
You have to build them with -fPIC, or simply use libtool, declare them as 
noinst_LTLIBRARIES, and libtool will take care of it linking them entirely 
inside the shared libraries using the PIC version.

Some packages ships with a libfoo_p.a archive built with PIC, too.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is ( http://farragut.flameeyes.is/ )-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

Re: linker error with new linker

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wednesday 12 July 2006 18:27, John Calcote wrote:
> However, the real question was: Does anyone know if there's a
> "standard" way of dealing with the "linking shared libraries from static
> libraries in autotools" issue?
You have to build them with -fPIC, or simply use libtool, declare them as 
noinst_LTLIBRARIES, and libtool will take care of it linking them entirely 
inside the shared libraries using the PIC version.

Some packages ships with a libfoo_p.a archive built with PIC, too.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linker error with new linker

[John Calcote]

Daniel,
 
Thanks for the info - yes, I just had a brain-fart when I typed that
LDFLAGS comment - it took me half a compile to realize that it had to be
in CFLAGS, not LDFLAGS. 
 
However, the real question was: Does anyone know if there's a
"standard" way of dealing with the "linking shared libraries from static
libraries in autotools" issue? I know this is not the automake forum,
but this is a linker issue, so I thought you guys might have a clue. :)
 
John

>>> Daniel Jacobowitz <drow@false.org> 7/12/2006 8:08 AM >>>
On Tue, Jul 11, 2006 at 11:08:12PM -0600, John Calcote wrote:
> If this assumption is correct, then I believe it's really a good
thing
> - we SHOULD use all -fPIC flagged code in shared libraries. But I'm
not
> sure why it's become important in this later version of the linker.

It has never worked fine, esp. on x86_64.  It's just the linker wasn't
as rigorous about telling you about the problem previously.

> SuSE Enterprise Linux 10 Beta 8 - ld is newer (whatever SuSE's
> packaging along with gcc 4.1.0-5): generates the above error. 
> Here's my problem. Convenience libraries are good. They allow us to
> break large sets of files up into smaller sets of objects (static
> libraries) that we can deal with from one build directory to another.
I
> can reference a static library later in my build easily from another
> directory. This is fairly common practice, I believe. With the advent
of
> this new linker error, what can I do to maintain this model? I don't
> ship the static convenience libraries as part of my package. They
just
> make the build system a bit more modular. Is there a recommended
> approach to fixing this issue without reorganizing my entire
automake
> system? 
>  
> For now, I going to try to override the static library flags LDFLAGS
> for the convenience libraries and force the -fPIC flag on, which
should
> work fine since I don't expect consumers to use these convenience
> libraries. But if there's a better way, please let me know.

LDFLAGS has nothing to do with it - you don't link archives.  Compile
all code that is destined to end up in a shared library with -fPIC (in
CFLAGS).

-- 
Daniel Jacobowitz
CodeSourcery