Re: [09/25] Specs cleanup: CRIS

["Joseph S. Myers" <joseph at codesourcery dot 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.  (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.)

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.  (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.)

-- 
Joseph S. Myers
joseph@codesourcery.com