[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binutils-bugs
Subject:    [Bug ld/29288] Dependent libraries cannot be found with default sysroot search dir and rpath using c
From:       "galaxyking0419 at gmail dot com" <sourceware-bugzilla () sourceware ! org>
Date:       2022-06-30 12:37:51
Message-ID: bug-29288-70-OviplX0JII () http ! sourceware ! org/bugzilla/
[Download RAW message or body]

https://sourceware.org/bugzilla/show_bug.cgi?id=29288

--- Comment #8 from William Tang <galaxyking0419 at gmail dot com> ---
(In reply to Alan Modra from comment #7)
> sysroot and rpath are complicated, and can be difficult to get right.  If
> using sysroot you have a linker that has access to your entire file system,
> but default searches should be as if the linker was chroot'd at the sysroot.
> 
> BFD ld adds the sysroot to absolute paths in rpath when searching for shared
> library dependencies, ie. libraries not mentioned on the command line but
> found in DT_NEEDED entries of other libraries.  If you accept that linking
> against libraries not mentioned on the command line is a good thing
> (debatable), then emulating the run-time loader is necessary.  Note that
> gold doesn't go searching for library dependencies, hence the gold
> difference.
> 
> I don't believe BFD ld prefixes -rpath paths with the sysroot in other
> circumstances.  (You definitely would not want the sysroot prefix added to
> DT_NEEDED in executables you create, since they then would have the wrong
> paths if copied over to a native environment.)
> 
> BFD ld also replaces an initial "=" or "$SYSROOT" in any -L or other
> paths with the sysroot.  If configured with a sysroot, the default
> library search paths have the "=" prefix.  eg. "=/usr/lib" and "=/lib".

Thanks for the detailed explanation.  But I still cannot understand why bfd ld
always add "SEARCH_DIR("=/usr/arm-linux-gnueabihf/lib");" (which expanded to
"/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf/lib") to the search dir
instead of something more reasonable like "SEARCH_DIR("=/lib");" (which
expanded to "/usr/arm-linux-gnueabihf/lib").  The former path is pointing to an
empty directory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
[prev in list] [next in list] [prev in thread] [next in thread]