Date: Sun, 19 Apr 2015 14:57:18 -0700 From: Waitman Gobble <gobble.wa@gmail.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org, Ian Lepore <ian@freebsd.org> Subject: Re: crochet build fails at ubldr Wandboard-Dual Message-ID: <CAFuo_fx-uqfThQhutvZugAK16HjY2sxtegRcGydkLu0Si_h6uQ@mail.gmail.com> In-Reply-To: <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.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>
next in thread | previous in thread | raw e-mail | index | archive | help
Waitman Gobble
Los Altos, California USA
510 830 7975
On Apr 19, 2015 1:26 PM, "Tim Kientzle" <tim@kientzle.com> wrote:
>
>
> >>>
> >>> Somebody reported this on IRC yesterday as well, but I can't reproduc=
e
> >>> it here. I don't use crochet, so it must be doing something a bit
> >>> different to end up with the lib from /usr instead of the local one i=
n
> >>> objdir. There should be no need to set LIBSTAND externally.
> >>>
> >>
> >> Thanks for the reply. Unfortunately I missed the discussion on IRC.
> >>
> >> I suppose I'll have to backtrack through and find out where it
> >> _should_ be set to solve the problem. (?) For now, the workaround gets
> >> the build to finish.
> >>
> >
> > It shouldn't be set anywhere, it should just work. That's kind of my
> > point... my build process is just the standard "make buildworld
> > TARGET_ARCH=3Darmv6hf UBDLR_ADDR=3D<whatever>" and it just works. I do=
n't
> > know what crochet is doing differently (and you only included a fragmen=
t
> > of the build log that didn't include the command used to start the
> > build).
> >
>
>
> Crochet does use the standard build machinery; the only significant
difference is that it builds ubldr separately after a successful
buildworld. Building ubldr separately allows it to reuse the buildworld
results when building for multiple boards with the same TARGET_ARCH but
varying UBLDR_LOADADDR.
>
> The detailed logic is in lib/freebsd.sh, I=E2=80=99ve pasted it below (wi=
th a few
variables substituted in and some error checking removed to clarify):
>
> cd ${FREEBSD_SRC}
> ubldr_makefiles=3D${FREEBSD_SRC}/share/mk
> buildenv=3D`make TARGET_ARCH=3D$TARGET_ARCH buildenvvars`
>
> cd ${FREEBSD_SRC}/sys/boot
> eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefiles o=
bj
> eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefiles
clean
> eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefiles
depend
> eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefiles a=
ll
>
> cd arm/uboot
> eval $buildenv make UBLDR_LOADADDR=3D0x11000000 DESTDIR=3D${UBLDR_DIR=
}/
BINDIR=3Dboot NO_MAN=3Dtrue -m $ubldr_makefiles install
>
> The last bit here is just a way to get the FreeBSD makefiles to copy the
built executable to a known location (otherwise, Crochet has to reproduce
the FreeBSD build system logic for determining which objdir layout to use).
>
> Cheers,
>
> Tim
>
Thanks,
So maybe its truly a documentation issue since everyone is convinced
crochet is correct. I didnt see that mentioned in the docs.
Waitman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFuo_fx-uqfThQhutvZugAK16HjY2sxtegRcGydkLu0Si_h6uQ>