From owner-freebsd-arm@FreeBSD.ORG Sat Apr 25 17:58:48 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 81A4F314; Sat, 25 Apr 2015 17:58:48 +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 29965196C; Sat, 25 Apr 2015 17:58:47 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t3PHwOJb053488; Sat, 25 Apr 2015 17:58:24 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 69bfvvniptze6rqkc4qrvkkph6; Sat, 25 Apr 2015 17:58:24 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: crochet build fails at ubldr Wandboard-Dual From: Tim Kientzle In-Reply-To: Date: Sat, 25 Apr 2015 10:58:23 -0700 Cc: Waitman Gobble , freebsd-arm , Ian Lepore Message-Id: References: <1429456908.1182.82.camel@freebsd.org> <1429458041.1182.86.camel@freebsd.org> <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.com> <32B72D5A-742C-4B58-AD65-EA33B306D30C@kientzle.com> To: "O'Connor, Daniel" X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sat, 25 Apr 2015 17:58:48 -0000 > 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. 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