Linker script and dependency search path

[Mike Frysinger]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20100523/608773c8/attachment.sig>