crochet build fails at ubldr Wandboard-Dual

[Tim Kientzle]

> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel <darius at dons.net.au> wrote:
> 
> 
>> On 20 Apr 2015, at 08:41, Tim Kientzle <tim at kientzle.com> 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