From owner-freebsd-arm@freebsd.org Sat Oct 14 01:53:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80F66E34BA4 for ; Sat, 14 Oct 2017 01:53:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-20.reflexion.net [208.70.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40CEE81F57 for ; Sat, 14 Oct 2017 01:53:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27380 invoked from network); 14 Oct 2017 01:53:58 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Oct 2017 01:53:58 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 13 Oct 2017 21:53:58 -0400 (EDT) Received: (qmail 7667 invoked from network); 14 Oct 2017 01:53:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Oct 2017 01:53:57 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 25943EC8E8B; Fri, 13 Oct 2017 18:53:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Difficulty with armv6 to v7 transition. From: Mark Millard In-Reply-To: <254A2C41-59A9-4E4E-8982-ADDBAE2B5F91@dsl-only.net> Date: Fri, 13 Oct 2017 18:53:56 -0700 Cc: freebsd-arm , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <5BD31011-03B0-47F6-B14B-82BDAB9E6B06@dsl-only.net> References: <20171009175216.GA52497@www.zefox.net> <1507573171.84167.9.camel@freebsd.org> <20171011023356.GA57571@www.zefox.net> <20171011030021.GB57571@www.zefox.net> <20171013020604.GA70845@www.zefox.net> <20171013175943.GA74121@www.zefox.net> <20171014010713.GA75288@www.zefox.net> <254A2C41-59A9-4E4E-8982-ADDBAE2B5F91@dsl-only.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 01:53:59 -0000 On 2017-Oct-13, at 6:27 PM, Mark Millard wrote: > On 2017-Oct-13, at 6:07 PM, bob prohaska wrote: >=20 >> Seems it would have been better to replace >> BUILD_ARCH!=3D uname -p >> with >> BUILD_ARCH!=3D echo armv7 >> for present purposes. Hmm. . . I looked at the history of those lines in this form and they go back to -r84136 (2001-Sep-29). That is the only usage of BUILD_ARCH in the file (at least currently). I doubt that these lines are wrong or were getting the problem that I observed: Otherwise other builds I've done would have failed. My failure context may be specific to poudriere based builds (or poudriere based cross builds). That would leave me guessing that ${MACHINE_ARCH} was not as expected for some reason. Again: I hope that the error message is changed to report the two (or three) strings as well (if possible). You might want to try something like: .error To cross-build, set TARGET_ARCH (MACHINE_ARCH=3D"${MACHINE_ARCH}" = BUILD_ARCH=3D"${BUILD_ARCH}" TARGET_ARCH=3D"${TARGET_ARCH}") with the uname -p in place. The values reported could be useful. (Sorry that I do not currently have a build environment that is appropriate to me to test my own ideas on this.) > Are you starting under armv6 ? armv7 ? > BUILD_ARCH should end up matching what > you start under, not the end target as > I understand things. >=20 > If I tried a cross build on a host > other than armv7 that BUILD_ARCH result > would be wrong. (I use amd64 for cross > building aarch64 and arm6 . I'm not up to > an armv7 capable context yet and may not > be for some time.) >=20 > That change is a local workaround that is > specific to the environment you are using > for a build. >=20 > This is like my 12.0-CURRENT change being > specific to my not building on 11.x or 10.x . > It is just a local workaround that applies > just to a more limited context. >=20 > I've not figured out what is going on (how/why) > for the !=3D uname behavior that I observed. But > echoing the expected result instead did work. >=20 > None of this is appropriate to check-in. >=20 > I'll stop the buildworld in progress and try it. Please report if echo of the host type of context appears to make your local environment work vs. not. If it does work then it suggests that !=3D uname -p did not get the expected text for some reason. Older material: On Fri, Oct 13, 2017 at 11:36:46AM -0700, Mark Millard wrote: > On 2017-Oct-13, at 10:59 AM, bob prohaska = wrote: >=20 >> It turns out that simply commenting out lines 447-452 in=20 >> /usr/src/Makefile.inc1 allows buildworld to run, even with >> no /etc/make.conf in place.=20 >=20 > For reference: >=20 > 447 .if make(buildworld) > 448 BUILD_ARCH!=3D uname -p > 449 .if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} > 450 .error To cross-build, set TARGET_ARCH. > 451 .endif > 452 .endif >=20 > (I suggest that the .error message include the > MACHINE_ARCH text and the BUILD_ARCH text, probably > with ""s around each so that empty is easy to see.) >=20 >=20 > I've had problems with Makefiles using !=3D and uname > ending up with the MACRO assigned being an empty string > despite a command-line uname returning the expected > text. >=20 > For example I've applied the below local work arounds > to my /usr/ports/Mk/bsd.port.mk copy as part of setting > up to do amd64 -> aarch64 or amd64 -> armv6 cross > builds of ports via poudriere (I've not updated to a > armv7-targeting vintage sources yet): >=20 >=20 > # Get the operating system type > .if !defined(OPSYS) > -OPSYS!=3D ${UNAME} -s > +OPSYS!=3D echo FreeBSD > .endif > _EXPORTED_VARS+=3D OPSYS >=20 > .if !defined(_OSRELEASE) > -_OSRELEASE!=3D ${UNAME} -r > +_OSRELEASE!=3D echo 12.0-CURRENT > .endif > _EXPORTED_VARS+=3D _OSRELEASE >=20 >=20 > I was specifically ending up with _OSRELEASE > being empty as seen in poudriere prior to the > workaround and that was messing up poudriere > such that it stopped with an associated > message. =3D=3D=3D Mark Millard markmi at dsl-only.net