From owner-freebsd-arm@FreeBSD.ORG Sun Apr 19 20:50:27 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B67C54D; Sun, 19 Apr 2015 20:50:27 +0000 (UTC) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43905BF7; Sun, 19 Apr 2015 20:50:26 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t3JKQLjq021013; Sun, 19 Apr 2015 20:26:21 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.105] (192.168.1.65 [192.168.1.65]) by kientzle.com with SMTP id cbv5xi2jevkfa9kfew9vtxt7ps; Sun, 19 Apr 2015 20:26:16 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: crochet build fails at ubldr Wandboard-Dual From: Tim Kientzle In-Reply-To: <1429458041.1182.86.camel@freebsd.org> Date: Sun, 19 Apr 2015 13:26:15 -0700 Cc: Waitman Gobble , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.com> References: <1429456908.1182.82.camel@freebsd.org> <1429458041.1182.86.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2070.6) 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 20:50:27 -0000 >>>=20 >>> Somebody reported this on IRC yesterday as well, but I can't = reproduce >>> 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 = in >>> objdir. There should be no need to set LIBSTAND externally. >>>=20 >>=20 >> Thanks for the reply. Unfortunately I missed the discussion on IRC. >>=20 >> 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. >>=20 >=20 > 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 = fragment > of the build log that didn't include the command used to start the > build). >=20 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 = (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_makefiles = obj 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 = 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 = reproduce the FreeBSD build system logic for determining which objdir = layout to use). Cheers, Tim