Date: Sat, 25 Apr 2015 10:58:23 -0700 From: Tim Kientzle <tim@kientzle.com> To: "O'Connor, Daniel" <darius@dons.net.au> Cc: Waitman Gobble <gobble.wa@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: crochet build fails at ubldr Wandboard-Dual Message-ID: <C90A1604-9018-47BF-9214-CB913EEADD80@kientzle.com> In-Reply-To: <A6E50B78-8694-4984-8984-12479303361E@dons.net.au> References: <CAFuo_fy5tPjQDbtuSwcBEt4UMuu2tv8zRLLwBrpZPUGcyEMKEA@mail.gmail.com> <CAFuo_fx6Ztb2Rn8dPmZ3HBJniChvkZX54qmF_oaA87LJeHCFFQ@mail.gmail.com> <1429456908.1182.82.camel@freebsd.org> <CAFuo_fzHtCF6F%2B%2BUGqSdhzvbkTjxRtoT8sXFKV%2BCr4UpsGmymQ@mail.gmail.com> <1429458041.1182.86.camel@freebsd.org> <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.com> <CAFuo_fx-uqfThQhutvZugAK16HjY2sxtegRcGydkLu0Si_h6uQ@mail.gmail.com> <32B72D5A-742C-4B58-AD65-EA33B306D30C@kientzle.com> <A6E50B78-8694-4984-8984-12479303361E@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel <darius@dons.net.au> =
wrote:
>=20
>=20
>> On 20 Apr 2015, at 08:41, Tim Kientzle <tim@kientzle.com> wrote:
>>>>=20
>>>> Crochet does use the standard build machinery; the only significant =
difference is that it builds ubldr separately after a successful =
buildworld. ...
>>>=20
>>> So maybe its truly a documentation issue since everyone is convinced =
crochet is correct. I didnt see that mentioned in the docs.
>>>=20
>> You=E2=80=99ve certainly encountered a problem but I don=E2=80=99t =
yet have enough information to say anything more. Certainly, Ian is =
right that you should not have to set LIBSTAND to make this work.
>>=20
>> Unfortunately, it will be at least a few days before I have a chance =
to try reproducing what you=E2=80=99re seeing. If you can reproduce it =
consistently, please let me know; I could work up some patches based on =
Ian=E2=80=99s suggestions and you could try them to see if they change =
anything.
>>=20
>> Another things to try: blow away Crochet=E2=80=99s work directory =
before you next rebuild. In particular, that will ensure that your =
world build and ubldr build are consistent with each other.
>=20
> 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+=3D =
-I${.CURDIR}/../../../../lib/libstand/
> # clang doesn't understand %D as a specifier to printf
> NO_WERROR.clang=3D
>=20
> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a
> +
> DPADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} =
${LIBSTAND}
> LDADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} =
-lstand
>=20
> 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=3D autoload.c \
> .PATH: ${.CURDIR}/../../i386/libi386
> .include "${.CURDIR}/arch/${MACHINE}/Makefile.inc"
>=20
> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a
> +
> CFLAGS+=3D -I${.CURDIR}
> CFLAGS+=3D -I${.CURDIR}/arch/${MACHINE}
> CFLAGS+=3D -I${.CURDIR}/../include
>=20
> 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+=3D -I${.CURDIR}/../../../../lib/libstand/
It definitely looks like a bug that it=E2=80=99s overriding the include =
path for libstand but not the library path. Just above this is a =
similar section for libuboot that overrides both.
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C90A1604-9018-47BF-9214-CB913EEADD80>