[rfc] dont use absolute paths in ldscripts if they arent needed

[Daniel Jacobowitz]

On Sun, Apr 02, 2006 at 01:07:30PM -0400, Mike Frysinger wrote:
> i'm not confusing things.

Well, you're sure confusing yourself.

> 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/.

This is silly.  You're using a sysroot configured toolchain, but you're
not putting things in the right place in the sysroot.

A sysroot is supposed to precisely resemble the root filesystem of a
target system.  If you have /usr/target configured as your sysroot,
then you'd better have configured glibc for --prefix=/usr and
installed it with install_root=/usr/target.

If the glibc you're building is actually supposed to search
"/usr/target/lib" when you run its dynamic linker, then it's not
configured for a sysroot; you're trying to use the sysroot support to
do something different.  If I understand what you're trying to do, you
might be able to get the right effect just by adding a /usr/target/usr/target ->
../.. symlink.

> the problem absolute paths in ldscripts 
> fixes simply doesnt not apply when libdir==slibdir, so why bother.

You are trying to fix "absolute paths in ldscripts don't work" by
fixing the one well-known source of such paths.  Why not configure your
tools so that absolute paths actually work, so that they don't bite
you from some other source?

-- 
Daniel Jacobowitz
CodeSourcery