This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH (top-level build machinery, mainline, ping1): Fix in-src 'strap

>> Could you please try making *every* target-[+module+] no_stage (which would
>> actually be a simpler patch since it wouldn't require the no_stage flag), and
>> see if that works?  (And if not, why not?)
>Ah, I actually attempted that before settling on the posted patch.
>The issue is target libraries which are also host libraries.  A
>concrete example helps display the problem (I don't fully understand
>the root cause or thus how to fix it).  Consider the following structure:
>When we don't stage the in-src configuration, what appears to happen
>is that the already built objects in $srcdir/gcc/libiberty satisfy
>Make VPATH lookup rules while building in $srcdir/gcc/<target-triple>/libiberty.
>This is not the case for $objdir configuration since no objects are ever
>populated with the source found via VPATH rules.
OK.  Let's keep this simple then.  The host-target overlap consists of


Could you work up a patch which converts *all other* target dirs to
no_stage semantics, while leaving these three with 'staged' behavior?
(You'll want to reverse the name and sense of your autogen variable.)

That way we can worry about those later.

>Humm, a perfectly clear way to fix this (now that we assume GNU make)
>would be to always create a host-triple directory in which to build
>all host libraries required by gcc...
Oh, I've wanted to do that for years.  ;-)  And I don't see that it's
dependent on GNU Make or even VPATH support, if done correctly.  But
that's a *big* change which would impact all of src.

Nathanael Nerode  <neroden at>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]