[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: RFA: new option

From: Ralf Corsepius
Subject: Re: Patch: RFA: new option
Date: 06 Aug 2003 07:33:06 +0200

On Wed, 2003-08-06 at 06:49, Tom Tromey wrote:
> >>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
> Tom> I'd like to get this in 1.7.7 so that we can start using it in gcc.
> adl> So that will be a "bug fix++" release.  If this can push
> adl> newer Automakes in the gcc tree I presume it's a Good Thing.
> Yeah, I think so.
> Tom> We're also looking forward to the post-1.7.6 multilib bug fixes.
> adl> I'm glad to hear that.  After Alexandre Oliva's comments [1]
> adl> I've been wondering whether fixing these rules was better than
> adl> removing them entirely.
> Well, I was using the royal "we", meaning me.  It will simplify a few
> Makefile.ams in the gcc tree.
> If gcc gets rid of and moves multilibs to the top level,
> that will be nice all around.
Could you elaborate? 

Besides of this being an opportunity to get rid of some of's "gross" internals, I don't understand why that would be

In contrary, AFAIU this would probably merge's internal
details (esp. the "filtering multilib exceptions") into the (AFAIU,
toplevel) configure script.

I also don't see that "toplevel-ing" multilibs helps wrt. other
deficiencies the current multilib-support implementation has (esp. with
deep subdirs in general and header installation).

>   The reason I pushed multilib code into
> automake was to avoid having (or was it user
> scripts?) add dependencies in an unsafe way.  Building them from the
> top level will mean we can just remove all the gross code.
> Having support for multilibs in a non-gcc tree is a different thing.
> It never occurred to me that somebody would want that.
We (RTEMS) are using multilibs w/ automake.

They currently are implemented by using customized versions of
automake-1.7.x's multi.m4 and + a customized gcc-3.4, because the versions shipped with automake up to now do
not suite to our needs and because we were hoping that multilib support
in automake once upon a day would reach a "usable" status (it currently

I.e. if you want to remove multilibs from automake, this probably will
not desturb us. However, I continue to think multilibs should be
improved, be generalized and be implemented in automake.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]