Home Original page

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

Geoff Keating geoffk@cygnus.com
Fri Jul 21 14:48:00 GMT 2000 
> Cc: Geoff Keating <geoffk@cygnus.com>, hjl@lucon.org, aoliva@cygnus.com,
>         gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com
> From: Jason Merrill <jason@redhat.com>
> Date: 21 Jul 2000 14:19:27 -0700
> 
> >>>>> Jim Wilson <wilson@cygnus.com> writes:
> 
>  > There are certainly differences in the build process.  HJ doesn't like
>  > to use the --with-headers= and --with-libs= options that we recommend.
> 
> I don't see how those options would help; as far as I can tell, all they do
> is copy the headers and libs from the specified locations into $(tooldir)
> and suppress newlib.  They don't seem to affect at all how the headers and
> libs are found.
> 
> When you build an ia64 toolchain, where does your crt0.o live?  How does
> the compiler find it?

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.  Under
the new scheme, you'll find crt0.o in

$prefix/sys-root/lib/crt0.o
or
$prefix/sys-root/usr/lib/crt0.o

depending on whether it'd be in /lib or /usr/lib in a native
environment.

(The current status is that it's all done but for linker issues---the
ideal would be that you could just copy /lib and /usr/lib and
/usr/include and whatever else, but on linux /usr/lib/libc.so is a ld
script file, with absolute pathnames, and so we want to reinterpret
the absolute pathnames relative to $prefix/sys-root, and probably for
other linker scripts too so that if they work on the native they'll
work in a cross envirnment.  Unfortunately the engineer involved is
swamped with other stuff right now.  Feedback would probably be
interesting.)
-- 
- Geoffrey Keating <geoffk@cygnus.com>
More information about the Binutils mailing list