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

Re: [Xen-devel] [XEN PATCH for-4.13] xen: Fix race to build arch/x86/efi/relocs-dummy.o



On 19.11.2019 17:27, Jan Beulich wrote:
> On 14.11.2019 19:05, Anthony PERARD wrote:
>> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
>> will attempt to build that object. This result in the dependency file
>> been generated with relocs-dummy.o depending on efi/relocs-dummy.o.
>>
>> Then, when arch/x86/efi/Makefile tries to build relocs-dummy.o, well
>> efi/relocs-dummy.S doesn't exist.
>>
>> Have only one makefile responsible for building relocs-dummy.o.
> 
> On a system with too old a tool chain for the EFI build to get
> enabled I now get about a dozen instances per build of
> 
> nm: 'efi/relocs-dummy.o': No such file
> 
> I don't suppose you did try out your change in such an oldish
> environment? I assume the problem are these two lines:
> 
> $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A 
> VIRT_START$$,,p')
> $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A 
> ALT_START$$,,p')
> 
> I'm not sure it is well defined when make would evaluate such
> target specific variable assignments (i.e. I'm not sure this
> doesn't point out an issue even on EFI capable tool chains).
> Then again these not using := should cause them to get
> evaluated only upon use, i.e. never.

Ah, this was wrong - the $(guard) prefix causes them to get
evaluated even when xen.efi cannot be built. So I guess this is
just a cosmetic issue then, which would however still be nice
to see addressed.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.