Intermittent efi libstub build errors on arm64

[Steve Capper]

On 6 March 2015 at 12:11, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 6 March 2015 at 12:09, Steve Capper <steve.capper at linaro.org> wrote:
>> On Fri, Mar 06, 2015 at 10:34:29AM +0000, Steve Capper wrote:
>>> Hi,
>>> I've run into some strange build errors with 3.19.
>>>
>>> If I set a high number of parallel jobs, I sometimes get build errors
>>> such as:
>>>
>>> mv: cannot stat ‘drivers/firmware/efi/libstub/.fdt.o.tmp’: No such file or directory
>>>   AR      drivers/firmware/efi/libstub/lib.a
>>> scripts/Makefile.build:257: recipe for target 'drivers/firmware/efi/libstub/fdt.o' failed
>>> make[1]: *** [drivers/firmware/efi/libstub/fdt.o] Error 1
>>> Makefile:939: recipe for target 'drivers/firmware/efi/libstub' failed
>>> make: *** [drivers/firmware/efi/libstub] Error 2
>>>
>>> and,
>>>
>>> fixdep: error opening depfile: drivers/firmware/efi/libstub/.efi-stub-helper.o.d: No such file or directory
>>> scripts/Makefile.build:257: recipe for target 'drivers/firmware/efi/libstub/efi-stub-helper.o' failed
>>> make[1]: *** [drivers/firmware/efi/libstub/efi-stub-helper.o] Error 2
>>> Makefile:939: recipe for target 'drivers/firmware/efi/libstub' failed
>>> make: *** [drivers/firmware/efi/libstub] Error 2
>>> make: *** Waiting for unfinished jobs....
>>>
>>>
>>> I think some dependency information/header includes may need tweaking
>>> somewhere. Has anyone else come across this, or know more?
>>>
>>
>> Having done some more digging, I believe it may be the libstub
>> directory being entered twice by the build system.
>>
>> I am testing the following patch out:
>> --- a/drivers/firmware/efi/Makefile
>> +++ b/drivers/firmware/efi/Makefile
>> @@ -7,4 +7,3 @@ obj-$(CONFIG_EFI_VARS_PSTORE)           += efi-pstore.o
>>  obj-$(CONFIG_UEFI_CPER)                        += cper.o
>>  obj-$(CONFIG_EFI_RUNTIME_MAP)          += runtime-map.o
>>  obj-$(CONFIG_EFI_RUNTIME_WRAPPERS)     += runtime-wrappers.o
>> -obj-$(CONFIG_EFI_STUB)                 += libstub/
>>
>> To see if the problem persists.
>>
>
> I have noticed something odd once or twice, but I thought it was just
> my stale build tree.
>
> In any case, removing this line will break x86, as it includes
> libstub/lib.a explicitly into its decompressor, so it needs the build
> system to traverse libstub/
> So we could either drop this and link arm64's vmlinux to libstub/lib.a
> explicitly as well, or conditionalize it on CONFIG_ARM64
>

Thanks Ard, whoops I didn't notice that!
It may be an idea to make arm64 behave similarly to x86 (link in libstub/lib.a)?

> (This all assuming this is the culprit)

I'll keep my stress tests running and will report back.

>
> Thanks,
> Ard.