crochet build fails at ubldr Wandboard-Dual

[Luiz Otavio O Souza]

On 25 April 2015 at 14:58, Tim Kientzle wrote:
>
>> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel  wrote:
>>
>>
>>> On 20 Apr 2015, at 08:41, Tim Kientzle wrote:
>>>>>
>>>>> Crochet does use the standard build machinery; the only significant difference is that it builds ubldr separately after a successful buildworld.  ...
>>>>
>>>> So maybe its truly a documentation issue since everyone is convinced crochet is correct. I didnt see that mentioned in the docs.
>>>>
>>> You’ve certainly encountered a problem but I don’t yet have enough information to say anything more.  Certainly, Ian is right that you should not have to set LIBSTAND to make this work.
>>>
>>> Unfortunately, it will be at least a few days before I have a chance to try reproducing what you’re seeing.  If you can reproduce it consistently, please let me know; I could work up some patches based on Ian’s suggestions and you could try them to see if they change anything.
>>>
>>> Another things to try:  blow away Crochet’s work directory before you next rebuild.  In particular, that will ensure that your world build and ubldr build are consistent with each other.
>>
>> I had this issue also and worked around it by modifying the loader Makefiles to set LIBSTAND.
>> diff --git a/sys/boot/arm/uboot/Makefile b/sys/boot/arm/uboot/Makefile
>> index e0ea828..cbd173e 100644
>> --- a/sys/boot/arm/uboot/Makefile
>> +++ b/sys/boot/arm/uboot/Makefile
>> @@ -113,6 +113,8 @@ CFLAGS+=    -I${.CURDIR}/../../../../lib/libstand/
>> # clang doesn't understand %D as a specifier to printf
>> NO_WERROR.clang=
>>
>> +LIBSTAND=      ${.OBJDIR}/../../../../lib/libstand/libstand.a
>> +
>> DPADD=         ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} ${LIBSTAND}
>> LDADD=         ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} -lstand
>>
>> diff --git a/sys/boot/efi/loader/Makefile b/sys/boot/efi/loader/Makefile
>> index 5585f78..55b8673 100644
>> --- a/sys/boot/efi/loader/Makefile
>> +++ b/sys/boot/efi/loader/Makefile
>> @@ -29,6 +29,8 @@ SRCS= autoload.c \
>> .PATH: ${.CURDIR}/../../i386/libi386
>> .include "${.CURDIR}/arch/${MACHINE}/Makefile.inc"
>>
>> +LIBSTAND=      ${.OBJDIR}/../../../../lib/libstand/libstand.a
>> +
>> CFLAGS+=       -I${.CURDIR}
>> CFLAGS+=       -I${.CURDIR}/arch/${MACHINE}
>> CFLAGS+=       -I${.CURDIR}/../include
>>
>> I did it that way because I noticed some other loader Makfiles set LIBSTAND so I assumed it was removed incorrectly from the arm and uefi ones.
>
> I think this is the right fix, though I would be more confident if I could locate the exact change that broke the earlier behavior.
>
> Certainly most of the other boot loader Makefiles do set LIBSTAND in this way, and arm/uboot/Makefile overrides a number of other libraries to ensure they are for the target architecture and not the host architecture.
>
> I also notice that sys/boot/arm/uboot/Makefile has the following:
>
> # where to get libstand from
> CFLAGS+=        -I${.CURDIR}/../../../../lib/libstand/
>
> It definitely looks like a bug that it’s overriding the include path for libstand but not the library path.  Just above this is a similar section for libuboot that overrides both.
>
> Tim

This issue was introduced by r281156 when andrew@ enabled the build of
efi/loader for ARM.

I don't know what is the right fix for this, but the following change
also works for me: http://pastie.org/10103315

The idea for this change comes from sys/boot/arm/uboot/Makefile.

HTH,
Luiz