Re: [09/25] Specs cleanup: CRIS

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Fri, 14 Jan 2011 18:08:42 +0000 (UTC)
> From: "Joseph S. Myers" <joseph@codesourcery.com>

> On Fri, 14 Jan 2011, Hans-Peter Nilsson wrote:
> 
> > > * cris/linux.h had specs passing -rpath-link options in some cases
> > >   (-B, or not -nostdlib).  This is not needed for any properly
> > >   configured cross toolchain (for GNU/Linux targets, that means using
> > >   a sysroot).
> > 
> > A sysroot configuration is not (should not be) mandatory for a
> > working cross-toolchain; no particular configure options at all
> > should be needed besides the --target option.  I understand
> > the confusion seeing that "down" in a port though.  I traced
> > this to
> > <http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01004.html>.
> 
> Since glibc installs a linker script as libc.so, with absolute paths in it 
> that need to be interpreted relative to the sysroot, you're not going to 
> have non-sysroot configurations working well without editing that linker 
> script at least.

Right, but that's not a contradiction, just an extra step at
glibc installation time and a limitation prohibiting relocating
installed toolchains without at least that edit.  The linked
message referred to an installed tree.  For an existing
installation (using the same --prefix), I'd like to think it's
obvious I *should* (continue to) be able to build a
non-sysrooted gcc that can access libraries and build against
that configuration but with newly build gcc-related libraries
overriding the installed ones, just like for a native
configuration.  It has worked in recent times, though needing
that -rpath-link spec stuff.  (I guess I should mention I
actually do gcc-4.3-based installations meaning I'm not just
cluelessly ranting.)  I hope that's not been broken beyond the
rpath-links needed, but I guess it'd be hard to break without
also breaking native builds!  (Note to self: really need to add
that autotester.)

Come to think of it, IIRC I've seen you in the front-line
arguing against differences between native and cross builds.
Don't you think at some level requiring an extra option, the
sysroot, for "well-working" cross-builds (and cross-testing) is
at least a wart?  (Perhaps fold that sysroot stuff so that all
cross-toolchains in fact are automatically sysrooted to their
prefix?)

brgds, H-P