This is the mail archive of the gcc-patches@gcc.gnu.org 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: PR bootstrap/18532: libgcc.mk isn't parallel build safe for multilib


"H. J. Lu" <hjl@lucon.org> writes:

>> 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.
>
> We need it since each multilib is built with
>
> $(MAKE) T=$dir ...
>
> "$dir" is different in each build.

I see.

> We may not do it in parallel safely, which is PR bootstrap/18532. We
> may only do it safely one multilib at a time.

Can you actually demonstrate a problem if the $prev_extra dependency
is removed, or is this just a theoretical issue?

>> 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.
>
> I removed my suffix.

Now it's not always set.  You have to hoist the existing definition
out of the SHLIB_LINK logic, like I said.

>> 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.
>
> Done.

Thanks.

Please correct the suffix setting and respond to my query above.

zw


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