From owner-freebsd-arm@FreeBSD.ORG Sun Apr 19 22:25:56 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F37F0627 for ; Sun, 19 Apr 2015 22:25:56 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i66.relay.mailchannels.net [184.154.112.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3A19B85B for ; Sun, 19 Apr 2015 22:25:55 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 3C69B1D042F; Sun, 19 Apr 2015 22:18:33 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sun, 19 Apr 2015 22:18:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1429481913367:3429792669 X-MC-Ingress-Time: 1429481913366 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp1.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YjxXs-00062N-WF; Sun, 19 Apr 2015 22:18:33 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t3JMIV5X028200; Sun, 19 Apr 2015 16:18:31 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+dA9imfQ6EJr6IBirB/7G1 Message-ID: <1429481911.1182.95.camel@freebsd.org> Subject: Re: crochet build fails at ubldr Wandboard-Dual From: Ian Lepore To: Waitman Gobble Cc: Tim Kientzle , freebsd-arm@freebsd.org Date: Sun, 19 Apr 2015 16:18:31 -0600 In-Reply-To: References: <1429456908.1182.82.camel@freebsd.org> <1429458041.1182.86.camel@freebsd.org> <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.com> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 X-AuthUser: hippie Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 22:25:57 -0000 On Sun, 2015-04-19 at 14:57 -0700, Waitman Gobble wrote: > Waitman Gobble > Los Altos, California USA > 510 830 7975 > On Apr 19, 2015 1:26 PM, "Tim Kientzle" wrote: > > > > > > >>> > > >>> Somebody reported this on IRC yesterday as well, but I can't repr= oduce > > >>> it here. I don't use crochet, so it must be doing something a bi= t > > >>> different to end up with the lib from /usr instead of the local o= ne in > > >>> 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" and it just works. = I don't > > > know what crochet is doing differently (and you only included a fra= gment > > > 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 buildworl= d > results when building for multiple boards with the same TARGET_ARCH but > varying UBLDR_LOADADDR. > > > > The detailed logic is in lib/freebsd.sh, I=FFve pasted it below (with= 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_makefil= es obj > > eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefil= es > clean > > eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefil= es > depend > > eval $buildenv make UBLDR_LOADADDR=3D0x11000000 -m $ubldr_makefil= es all > > > > 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 reprodu= ce > the FreeBSD build system logic for determining which objdir layout to u= se). > > > > Cheers, > > > > Tim > > >=20 > Thanks, >=20 > So maybe its truly a documentation issue since everyone is convinced > crochet is correct. I didnt see that mentioned in the docs. >=20 > Waitman I'm not in at all convinced that crochet is correct. It used to work and now it doesn't, but maybe it used to work by accident and some recent change has made that accident less fortunate. The technique Tim mentions above of using "eval $buildenv" strikes me as fragile at best. It might be a bit better if eval were replaced with env. To be really robust it should probably be something like "make buildworld installworld SUBDDIR_OVERRIDE=3Dsys/boot TARGET_ARCH=3Dwhatever UBLDR_LOADADDR=3Dwhatever DESTDIR=3Dwhatever" -- Ian