Date: Sun, 26 Apr 2015 13:10:55 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Luiz Otavio O Souza <lists.br@gmail.com> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: crochet build fails at ubldr Wandboard-Dual Message-ID: <0DADE75A-8680-4DEB-86AE-8764ACA4504C@cs.huji.ac.il> In-Reply-To: <CAB=2f8yOOqp0bQFrcJ9ZFmXsVLNNm%2B%2Be95OZcB0d8VZ6PzDhbQ@mail.gmail.com> 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> <C90A1604-9018-47BF-9214-CB913EEADD80@kientzle.com> <CAB=2f8yOOqp0bQFrcJ9ZFmXsVLNNm%2B%2Be95OZcB0d8VZ6PzDhbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 25, 2015, at 10:28 PM, Luiz Otavio O Souza <lists.br@gmail.com> =
wrote:
>=20
> On 25 April 2015 at 14:58, Tim Kientzle wrote:
>>=20
>>> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel wrote:
>>>=20
>>>=20
>>>> On 20 Apr 2015, at 08:41, Tim Kientzle 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> I also notice that sys/boot/arm/uboot/Makefile has the following:
>>=20
>> # where to get libstand from
>> CFLAGS+=3D -I${.CURDIR}/../../../../lib/libstand/
>>=20
>> 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.
>>=20
>> Tim
>=20
> This issue was introduced by r281156 when andrew@ enabled the build of
> efi/loader for ARM.
>=20
> 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>;
>=20
> The idea for this change comes from sys/boot/arm/uboot/Makefile.
>=20
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DADE75A-8680-4DEB-86AE-8764ACA4504C>