Re: [09/25] Specs cleanup: CRIS

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

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

> On Fri, 14 Jan 2011, Hans-Peter Nilsson wrote:
> 
> > 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?)
> 
> Sysrooting to the prefix is inappropriate since lib/ is for host 
> libraries, not target ones.  Sysrooting to prefix/$target is also 
> inappropriate (except maybe for GNU Hurd) since the native system layout 
> puts various things in /usr/include and /usr/lib, rather than /include and 
> /lib.
>
> I think non-sysroot toolchains should be considered the special, somewhat 
> deprecated case for cross tools to GNU/Linux targets (more generally: for 
> crosses to any target for which the concept of a native filesystem layout 
> makes sense), and sysrooted ones the case that is closer to the native 
> case.

It sounds like you believe sysroot is the preferable method for
cross-builds, yet arguing against defaulting to it, only from
the point that there's currently no suitable sysroot-point
within --prefix.  How about making up one?  Or wait, seems like
there already is one, ${exec_prefix}/${target_noncanonical}/sys-root
(used for --with-sysroot=yes).  Looks like we could just flip
the default, defaulting to --with-sysroot=yes for cross-builds.
Old-style installations would have to add --without-sysroot to
build scripts to "stay out".  Maybe I'm missing something: that
sounds way too simple to not have happened yet...

> (And it would be good to have an option for GCC to install all its 
> libraries in the sysroot paths rather than $target/lib etc., to reduce 
> differences further and settle on one set of paths for all libraries.)

I'm not sure I understand that correctly; does "make install"
not install target libraries in the configured sysroot if
--with-sysroot is given?  Now *there's* a wart!

> As for testing, if it's build-tree testing with a mixture of installed 
> glibc libraries and build-tree GCC libraries, the problem there is 
> differences between an installed compiler and a build tree one and I think 
> it's up to the test harness to pass all required -B, -rpath-link etc. 
> options if those options aren't needed with an installed
> compiler.

Sure, that's one of the reasons I ok'd your patch. ;-)
(It was likely not building that required those -rpath-links,
rather testing.  I definitely have to revisit.)

>  (And 
> the real solution is installed testing with staged installs: test 
> something closer to how the compilers will be used by making build-tree 
> testing actually create a temporary tree with the new compilers and the 
> installed binutils, glibc etc. binaries, so no special -B options are 
> needed and everything runs from a single tree.)

Yes, but... the half-way-installation method still has to
consider that it's not the final installation point.
Alternatively, everything done at "make all" would have to
change to prepare for installation anywhere (or at least both
$prefix and within the build tree) rather than just $prefix.
A decent amount of work just waiting for Someone. ;-)
Anyway, we're now digressing; this'd be a universal change, not
strictly tied to cross-builds.

brgds, H-P