This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR bootstrap/18532: libgcc.mk isn't parallel build safe for multilib
"H. J. Lu" <hjl@lucon.org> writes:
> On Wed, Dec 01, 2004 at 05:16:30PM -0800, Zack Weinberg wrote:
>> "H. J. Lu" <hjl@lucon.org> writes:
>>
>> > I updated my patch for PR bootstrap/18532 since mklibgcc.in has been
>> > modified.
>>
>> I'm not terribly confident in this patch. Could you please show
>> before-and-after diffs of the generated libgcc.mk for a target that
>> uses EXTRA_MULTILIB_PARTS? That will make it easier to evaluate.
>>
>
> I fixed some typos. Here is the updated patch and old/new libgcc.mks.
Thanks (but I asked for diffs, not complete copies of old and new
files).
I don't see the need for the dependency on $prev_extra, could you
explain why that is there? I'd think it would be preferable either
to invoke recursive make just once with *all* the EXTRA_MULTILIB_PARTS
targets (across all the multilibs) or else to allow the recursive
makes for each multilib to run in parallel.
Also, some nitpicks: You should hoist the definition of $suffix
from where you have it (and from the other place it appears, in the
SHLIB_LINK logic at the beginning of the loop over all multilibs) to
next to the definition of $dir and $flags, and add it to the set of
variables printed out in comments for each multilib.
The \$(filter-out $foobar_so_extra,\$(objects)) nonsense in the shared
library link, and therefore the need to keep $foobar_so_extra around,
should now be unnecessary; please take that out and retest.
zw