This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: create a BUILD libiberty.a
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: Patch: create a BUILD libiberty.a
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 16 Feb 2000 21:30:34 -0700
- cc: geoffk at cygnus dot com, rth at cygnus dot com, gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <200002161934.OAA19308@caip.rutgers.edu>you write:
> > From: Richard Henderson <rth@cygnus.com>
> >
> > On Mon, Feb 14, 2000 at 03:00:36PM -0800, Geoff Keating wrote:
> > > egcs/i386-ibm-linux-gnu/libiberty
> > > egcs/sparc-sun-solaris2.6/libiberty
> > > egcs/powerpc-unknown-eabi/libiberty
> > > egcs/powerpc-unknown-eabi/soft-float/libiberty
> > > egcs/powerpc-unknown-eabi/ca/libiberty
> > > egcs/powerpc-unknown-eabi/ca/soft-float/libiberty
> >
> > I like this a lot better than egcs/build-libiberty/ or whatever.
> > r~
>
>
> The problem with this is that when host==build==target, you get
> overlapping directory names.
But in that case we only need to build one set of libraries (ie, we don't
need separate host, build & target).
> Then multilibbing is hosed, especially
> if you built host/build libiberty with cc because the Makefile will
> think that the multilibbed target/libiberty is already built with the
> gcc just bootstrapped, whereas in reality it was created with cc.
Just as important -- we can't necessarily proper multilib when building
with cc since the options necessary to create specific sets of libraries
are likely going to be different from what gcc thinks they should be.
OK. I see what you're getting at. At least for now I think we need to
keep the host, build & target libraries separate.
jeff