Linker script and dependency search path

Linker script and dependency search path

[Ludovic Courtès]

Hello,

I’m in the process of building a GNU/Linux -> GNU (aka. GNU/Hurd) cross
toolchain.

On GNU, libc.so.0* depends on libhurduser.so and libmachuser.so, which
it lists as NEEDED.  libc.so itself is a linker script similar to that
found on GNU/Linux, and it doesn’t mention libhurduser.so and
libmachuser.so.

While building the final cross-GCC, linking fails because the cross ld
cannot find libhurduser.so and libmachuser.so, leading to undefined
references in libc.so.0*.

Adding -L/path/to/libc, or LIBRARY_PATH=/path/to/libc, or adding
/path/to/libc to the RUNPATH of libc.so.0* doesn’t solve the problem
(libhurduser and libmachuser are in the same directory as libc.so.)

So, is ld supposed to honor RUNPATH from libc.so.0*, given that this
shared library is only referenced from a ‘GROUP’ command in libc.so?
What are the search paths used for dependencies of shared libraries
mentioned in a ‘GROUP’ command?

Thanks,
Ludo’.

Re: Linker script and dependency search path

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 718 bytes --]

On Wednesday 19 May 2010 03:14:53 Ludovic Courtès wrote:
> Adding -L/path/to/libc, or LIBRARY_PATH=/path/to/libc, or adding
> /path/to/libc to the RUNPATH of libc.so.0* doesn’t solve the problem
> (libhurduser and libmachuser are in the same directory as libc.so.)

are you not using sysroots ?

> So, is ld supposed to honor RUNPATH from libc.so.0*, given that this
> shared library is only referenced from a ‘GROUP’ command in libc.so?
> What are the search paths used for dependencies of shared libraries
> mentioned in a ‘GROUP’ command?

i dont think so.  if you didnt want to use sysroots for some weird reason, an 
alternative might be to use the full path in the linker script.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Linker script and dependency search path

[Hans-Peter Nilsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 485 bytes --]

On Wed, 19 May 2010, Ludovic Courtès wrote:
> While building the final cross-GCC, linking fails because the cross ld
> cannot find libhurduser.so and libmachuser.so, leading to undefined
> references in libc.so.0*.
>
> Adding -L/path/to/libc, or LIBRARY_PATH=/path/to/libc, or adding
> /path/to/libc to the RUNPATH of libc.so.0* doesn?t solve the problem
> (libhurduser and libmachuser are in the same directory as libc.so.)

You're looking for -rpath-link; cf. ld.info.

brgds, H-P

Re: Linker script and dependency search path

[Ludovic Courtès]

Hi,

Mike Frysinger <vapier@gentoo.org> writes:

> On Wednesday 19 May 2010 03:14:53 Ludovic Courtès wrote:
>> Adding -L/path/to/libc, or LIBRARY_PATH=/path/to/libc, or adding
>> /path/to/libc to the RUNPATH of libc.so.0* doesn’t solve the problem
>> (libhurduser and libmachuser are in the same directory as libc.so.)
>
> are you not using sysroots ?

No.

>> So, is ld supposed to honor RUNPATH from libc.so.0*, given that this
>> shared library is only referenced from a ‘GROUP’ command in libc.so?
>> What are the search paths used for dependencies of shared libraries
>> mentioned in a ‘GROUP’ command?
>
> i dont think so.  if you didnt want to use sysroots for some weird reason, an 
> alternative might be to use the full path in the linker script.

Yes, that’s what I ended up doing.

Hans-Peter Nilsson <hp@bitrange.com> writes:

> On Wed, 19 May 2010, Ludovic Courtès wrote:
>> While building the final cross-GCC, linking fails because the cross ld
>> cannot find libhurduser.so and libmachuser.so, leading to undefined
>> references in libc.so.0*.
>>
>> Adding -L/path/to/libc, or LIBRARY_PATH=/path/to/libc, or adding
>> /path/to/libc to the RUNPATH of libc.so.0* doesn?t solve the problem
>> (libhurduser and libmachuser are in the same directory as libc.so.)
>
> You're looking for -rpath-link; cf. ld.info.

Yes, but that’s inconvenient for the libc itself: I find it more
convenient if linking with glibc just works without passing additional
flags (as on GNU/Linux), and augmenting the linker script does that
nicely.

In the meantime I noticed that the ld manual explicitly mentions that
RUNPATH is not honored by cross-linkers (info "(ld) Options").

Thanks for your answers,
Ludo’.

Re: Linker script and dependency search path

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 945 bytes --]

On Thursday 20 May 2010 05:35:25 Ludovic Courtès wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
> > You're looking for -rpath-link; cf. ld.info.
> 
> Yes, but that’s inconvenient for the libc itself: I find it more
> convenient if linking with glibc just works without passing additional
> flags (as on GNU/Linux), and augmenting the linker script does that
> nicely.

you get the same behavior with glibc+linux cross-compilers.  if you dont use a 
sysrooted toolchain, the linker scripts have troubles finding things.  so 
you'd either have to tweak the linker scripts to use the full paths as found 
on your development systems (and make it unusable on a native system), or use 
a sysrooted toolchain.

the advantage of a sysrooted toolchain is that the sysroot is fully usable 
both with the cross-compiler and as a native chroot with 0 changes.  so often 
i will nfsroot that sysroot directly via nfsroot.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Linker script and dependency search path

[Hans-Peter Nilsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 673 bytes --]

On Thu, 20 May 2010, Ludovic Courtès wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
> > You're looking for -rpath-link; cf. ld.info.
>
> Yes, but that?s inconvenient for the libc itself: I find it more
> convenient if linking with glibc just works without passing additional
> flags (as on GNU/Linux), and augmenting the linker script does that
> nicely.

I forgot how I actually do it: everything works nicely after you
edit the installed linker-scripts libc.so and libpthread.so to
include the full paths to the mentioned files; no sysroots or
-rpath-links needed (except of course when building another
library that depends on yet another library).

brgds, H-P

Re: Linker script and dependency search path

[Ludovic Courtès]

Hi,

Mike Frysinger <vapier@gentoo.org> writes:

> On Thursday 20 May 2010 05:35:25 Ludovic Courtès wrote:
>> Hans-Peter Nilsson <hp@bitrange.com> writes:
>> > You're looking for -rpath-link; cf. ld.info.
>> 
>> Yes, but that’s inconvenient for the libc itself: I find it more
>> convenient if linking with glibc just works without passing additional
>> flags (as on GNU/Linux), and augmenting the linker script does that
>> nicely.
>
> you get the same behavior with glibc+linux cross-compilers.  if you dont use a 
> sysrooted toolchain, the linker scripts have troubles finding things.

There’s a significant difference though: on GNU/Linux doesn’t have
anything NEEDED (except ld-linux.so).

Thanks,
Ludo’.

Re: Linker script and dependency search path

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 924 bytes --]

On Friday 21 May 2010 10:05:18 Ludovic Courtès wrote:
> Mike Frysinger writes:
> > On Thursday 20 May 2010 05:35:25 Ludovic Courtès wrote:
> >> Hans-Peter Nilsson <hp@bitrange.com> writes:
> >> > You're looking for -rpath-link; cf. ld.info.
> >> 
> >> Yes, but that’s inconvenient for the libc itself: I find it more
> >> convenient if linking with glibc just works without passing additional
> >> flags (as on GNU/Linux), and augmenting the linker script does that
> >> nicely.
> > 
> > you get the same behavior with glibc+linux cross-compilers.  if you dont
> > use a sysrooted toolchain, the linker scripts have troubles finding
> > things.
> 
> There’s a significant difference though: on GNU/Linux doesn’t have
> anything NEEDED (except ld-linux.so).

that isnt true ... glibc linker scripts pull in libc_nonshared.a too.  but 
even the ldso needs to be looked up & located somehow.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Linker script and dependency search path

[Ludovic Courtès]

Hi,

Mike Frysinger <vapier@gentoo.org> writes:

> On Friday 21 May 2010 10:05:18 Ludovic Courtès wrote:
>> Mike Frysinger writes:
>> > On Thursday 20 May 2010 05:35:25 Ludovic Courtès wrote:
>> >> Hans-Peter Nilsson <hp@bitrange.com> writes:
>> >> > You're looking for -rpath-link; cf. ld.info.
>> >> 
>> >> Yes, but that’s inconvenient for the libc itself: I find it more
>> >> convenient if linking with glibc just works without passing additional
>> >> flags (as on GNU/Linux), and augmenting the linker script does that
>> >> nicely.
>> > 
>> > you get the same behavior with glibc+linux cross-compilers.  if you dont
>> > use a sysrooted toolchain, the linker scripts have troubles finding
>> > things.
>> 
>> There’s a significant difference though: on GNU/Linux doesn’t have
>> anything NEEDED (except ld-linux.so).
>
> that isnt true ... glibc linker scripts pull in libc_nonshared.a too.  but 
> even the ldso needs to be looked up & located somehow.

Sorry, I wasn’t clear:

--8<---------------cut here---------------start------------->8---
$ uname -o
GNU/Linux
$ objdump -x ~/.nix-profile/lib/libc.so.6 |grep NEEDED
  NEEDED               ld-linux-x86-64.so.2
--8<---------------cut here---------------end--------------->8---

compared to:

--8<---------------cut here---------------start------------->8---
$ uname -o
GNU
$ objdump -x /lib/libc.so.0.3 |grep NEEDED
  NEEDED               ld.so.1
  NEEDED               libmachuser.so.1
  NEEDED               libhurduser.so.0.3
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.

Re: Linker script and dependency search path

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1648 bytes --]

On Saturday 22 May 2010 05:15:44 Ludovic Courtès wrote:
> Mike Frysinger writes:
> > On Friday 21 May 2010 10:05:18 Ludovic Courtès wrote:
> >> Mike Frysinger writes:
> >> > On Thursday 20 May 2010 05:35:25 Ludovic Courtès wrote:
> >> >> Hans-Peter Nilsson <hp@bitrange.com> writes:
> >> >> > You're looking for -rpath-link; cf. ld.info.
> >> >> 
> >> >> Yes, but that’s inconvenient for the libc itself: I find it more
> >> >> convenient if linking with glibc just works without passing
> >> >> additional flags (as on GNU/Linux), and augmenting the linker script
> >> >> does that nicely.
> >> > 
> >> > you get the same behavior with glibc+linux cross-compilers.  if you
> >> > dont use a sysrooted toolchain, the linker scripts have troubles
> >> > finding things.
> >> 
> >> There’s a significant difference though: on GNU/Linux doesn’t have
> >> anything NEEDED (except ld-linux.so).
> > 
> > that isnt true ... glibc linker scripts pull in libc_nonshared.a too. 
> > but even the ldso needs to be looked up & located somehow.
> 
> Sorry, I wasn’t clear:
> 
> --8<---------------cut here---------------start------------->8---
> $ uname -o
> GNU/Linux
> $ objdump -x ~/.nix-profile/lib/libc.so.6 |grep NEEDED
>   NEEDED               ld-linux-x86-64.so.2
> --8<---------------cut here---------------end--------------->8---

ok, in this case, your statement still isnt always true :).  many embedded 
arches need libgcc_s.so.x in their libc.so due to missing math funcs in 
hardware.  but yes, if you compare to a more "desktop" or "server" proc like 
x86, only the ldso will typically be needed.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]