crochet build fails at ubldr Wandboard-Dual

[Daniel Braniss]

> On Apr 25, 2015, at 10:28 PM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
> 
> 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 <http://pastie.org/10103315>
> 
> The idea for this change comes from sys/boot/arm/uboot/Makefile.
> 

the addition of efi is causing other problems too.
I first tried crochet for arm/current, and kept hitting the libstand.a issue,
so I tried cd ..src/ and make with all the flags (including -j16), and succeeded
but failed in install.
i use 10.1 to cross compile for arm/current,  so I commented out efi in Makefile.arm, and it installed ok.

danny