From owner-freebsd-arm@FreeBSD.ORG Sat Apr 25 19:28:57 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 4AD57690; Sat, 25 Apr 2015 19:28:57 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D14EB119B; Sat, 25 Apr 2015 19:28:56 +0000 (UTC) Received: by widdi4 with SMTP id di4so57252919wid.0; Sat, 25 Apr 2015 12:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qt61GbJpk/e/R5fOueXwrJj5Nq5lItjWAQRgClWsfqM=; b=uKAoggF0y73wnhthyoRv/tLoh4/d0cxZ3V0P6BvlmKNq3ie7ISIXmAbWvDgyVf76Js aSJ5L2xOnV+GJZsG/qB64uJNE7hKnZapOfhlAzleWGF4dYV6YS2b3121v2EPlNraXQO9 24k27+4WS9sFx1/5FHFIZmTVL79/UwXPAU5iL5Z5jgjLhU5olLrvVGRQ/ZYf2A/DZDGB eiVfVoYG0FGJWNjVO5qsNfUkGfyQiPO4iEfddfGZjsXiVnS/mDF93KnsWg+lkUMhzmSc ASFXUHKMk50DwAFDMtLRnmw5+VSkHPZL3xZsFmp/KLrzXympzkiD1J2iTmI8NQAB4Ck8 2lcQ== MIME-Version: 1.0 X-Received: by 10.194.118.135 with SMTP id km7mr8266994wjb.125.1429990135298; Sat, 25 Apr 2015 12:28:55 -0700 (PDT) Received: by 10.180.85.104 with HTTP; Sat, 25 Apr 2015 12:28:55 -0700 (PDT) In-Reply-To: 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> Date: Sat, 25 Apr 2015 16:28:55 -0300 Message-ID: Subject: Re: crochet build fails at ubldr Wandboard-Dual From: Luiz Otavio O Souza To: Tim Kientzle Cc: "O'Connor, Daniel" , freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 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: Sat, 25 Apr 2015 19:28:57 -0000 On 25 April 2015 at 14:58, Tim Kientzle wrote: > >> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel wrote: >> >> >>> On 20 Apr 2015, at 08:41, Tim Kientzle wrote: >>>>> >>>>> Crochet does use the standard build machinery; the only significant d= ifference is that it builds ubldr separately after a successful buildworld.= ... >>>> >>>> So maybe its truly a documentation issue since everyone is convinced c= rochet is correct. I didnt see that mentioned in the docs. >>>> >>> 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. >>> >>> 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 consi= stently, 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. >>> >>> Another things to try: blow away Crochet=E2=80=99s work directory befo= re you next rebuild. In particular, that will ensure that your world build= and ubldr build are consistent with each other. >> >> I had this issue also and worked around it by modifying the loader Makef= iles 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 >> >> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a >> + >> DPADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} ${LIBS= TAND} >> LDADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} -lstan= d >> >> 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" >> >> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a >> + >> CFLAGS+=3D -I${.CURDIR} >> CFLAGS+=3D -I${.CURDIR}/arch/${MACHINE} >> CFLAGS+=3D -I${.CURDIR}/../include >> >> I did it that way because I noticed some other loader Makfiles set LIBST= AND 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 coul= d 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 ensur= e 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 p= ath for libstand but not the library path. Just above this is a similar se= ction for libuboot that overrides both. > > Tim This issue was introduced by r281156 when andrew@ enabled the build of efi/loader for ARM. I don't know what is the right fix for this, but the following change also works for me: http://pastie.org/10103315 The idea for this change comes from sys/boot/arm/uboot/Makefile. HTH, Luiz