Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Angela Marie Thomas <angela at cygnus dot com>]

> 	I wouldn't try to do much work in this area for a bit.  Red Hat is
> 	working on some major changes to how hostXhost toolchains work.
> 
> Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
> 	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
> but the current stuff might be a bit different as that was 6 months ago.
> It would be useful to know if this mechanism works for H.J. as he has his
> own contraints that are rather different from ours.
> 
> Jim

It's a subset of Brendan's patch plus cleaner configury plus location
independence.  It will work for anyone who wishes to build a properly
working cross compiler targeting what we would call a native host and
is also being tested against vxworks, the only RTOS there is any serious
support for in gcc and which uses the current --with-headers/--with-libs
configury (eCos doesn't count as it does not use a specially configured
compiler).

The intent is for the usage of the cross compiler to be identical to
that of the native compiler equivalent.  A user who has a Makefile which
works for the native compiler equivalent should be able to prepend the
target triple (i.e. sparc-sun-solaris2.5, powerpc-unknown-linux) to the
tools used and produce the same binaries as the native build.

The changes obsolete --with-headers and --with-libs and isolate all of
the potentially proprietary target-specifc files to a single location
(exec-prefix/target/sys-root) which can be updated independently of the
tools modulo rerunning fixincludes in the case of header file updates.

I'm testing against a variety of hosts and so far it's worked extremely
well and solved many of the cross compiler issues we've had in the past.
I'm also planning to test it against the newest ia64 sources to compare
against the behavior of the previous cross compilers we built and tested.

I do not know what constraings H.J. could have which would conflict
with creating a cross compiler which behaves identically to the native
equivalent.  I'd be very interested in hearing what those might be as
I have a great deal of experience working with these compilers as you
well know.

--Angela