This is the mail archive of the
mailing list for the glibc project.
Re: [rfc] dont use absolute paths in ldscripts if they arent needed
On Sunday 02 April 2006 12:37, Daniel Jacobowitz wrote:
> On Sun, Apr 02, 2006 at 05:44:29AM -0400, Mike Frysinger wrote:
> > i've been playing with cross-compilers in Gentoo when i noticed that the
> > ldscripts installed by glibc always use full paths. in a normal setup,
> > these are clearly required as libc.so.6 goes in /lib/ while libc.so goes
> > in /usr/lib/. in a cross-compiler setup though, you usually have
> > libc.so.6 and libc.so in the same directory (like /usr/target/lib/).
> > encoding this full path can cause problems when using sysroot options
> > with binutils and gcc. crosstool gets around this by simply running a
> > sed on the linker scripts and deleting all leading path elements.
> You're confusing two different things here. If you use a sysrooted
> toolchain, this is a non-problem; the linker prepends the sysroot
> to the absolute path. If you are using /usr/foo-linux/lib, then you're
> probably not using a sysroot.
i'm not confusing things. when i said problems, i didnt mean binutils was
trying to access the wrong libraries. i know ld will automatically prepend
the sysroot path when presented with an absolute path in the linker script.
the fact that it prepends is the problem. we experimented with building
glibc with --prefix=/usr/target/ so that the install wouldnt put crap in /
or /usr since that would conflict with the native glibc. this would cause
the ldscripts to use paths such as /usr/target/lib/libc.so.6 which would
cause ld to search for /usr/target/lib/libc.so.6 in the sysroot
of /usr/target/. we could use the "magic" prefix of /usr, but then we'd have
to add a lot of crap to move libraries/executables/includes/etc... around and
that's just as much of a hack imo. the problem absolute paths in ldscripts
fixes simply doesnt not apply when libdir==slibdir, so why bother.