Problem with sparc64-linux /usr/lib64 hardcoded

[Geoff Keating]

Andreas Jaeger <aj@suse.de> writes:

> I've build a cross compiler from i686-linux to sparc64-linux to build
> glibc.  The specfile contains hardcoded the directory /usr/lib64 for
> e.g. crti.o.  This leads to the following failure building glibc:
> 
> /opt/sparc64-cross/lib/gcc-lib/sparc64-linux/2.96/../../../../sparc64-linux/bin/ld: cannot open /usr/lib64/crti.o: No such file or directory
> 
> Is there no other way than hardcoding /usr/lib64?  For example endfile
> has:
> *endfile:
> %{m32:%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s} %{m64:%{!shared:crtend.o%s} %{shared:crtendS.o%s} /usr/lib64/crtn.o%s} %{!m32:%{!m64:%{!shared:crtend.o%s} %{shared:crtendS.o%s} /usr/lib64/crtn.o%s}}
> 
> IMO we shouldn't use /usr/lib64 here - especially not in a cross-build
> with --prefix=/opt/sparc64-cross.  But how should it be handled?

Red Hat is working on code to look in

/opt/sparc64-cross/sparc64-linux/sys-root/usr/lib64/crtn.o

and so on for such things---essential if you also have a

/opt/sparc64-cross/sparc64-linux/sys-root/usr/lib/crtn.o

and want to be able to write -m32 and have it just work.  It's not
done yet.  I don't think it'd be a waste of time to try to implement
it again especially if you can learn from the successes of the current
patch (and are told where all the land mines are in advance...).

-- 
- Geoffrey Keating <geoffk@cygnus.com>