From owner-freebsd-arm@freebsd.org Sat Oct 14 05:47:00 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 C6C6CE3DAF3 for ; Sat, 14 Oct 2017 05:47:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86EB3642E9; Sat, 14 Oct 2017 05:47:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v9E5l72A076038 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Oct 2017 22:47:08 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v9E5l6WS076037; Fri, 13 Oct 2017 22:47:06 -0700 (PDT) (envelope-from fbsd) Date: Fri, 13 Oct 2017 22:47:06 -0700 From: bob prohaska To: mmel@freebsd.org Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Difficulty with armv6 to v7 transition. Message-ID: <20171014054706.GC75288@www.zefox.net> References: <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> <20171014021133.GB75288@www.zefox.net> <39f6419f-48f3-aaec-dfa4-3048c8a893d8@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39f6419f-48f3-aaec-dfa4-3048c8a893d8@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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 05:47:00 -0000 Hi Michal, On Sat, Oct 14, 2017 at 06:28:13AM +0200, Michal Meloun wrote: > Bob, > can you please try this? > setenv MACHINE_ARCH armv7; make buildworld TARGET=arm TARGET_ARCH=armv7 > I _believe_ I did try that, with no success, but the scrollback buffer isn't long enough to let me verify it. Right now the machine is running buildworld, using BUILD_ARCH!= echo armv7 in /usr/src/Makefile.inc1 to set BUILD_ARCH. If the buildworld fails I'll try setenv, just to verify. Should know late Saturday or early Sunday. A more immediate puzzle is how to test whether the buildworld command produced an armv7 userland, or something else, before running installworld. I'd hate to trash the system _again_. Running clang -v ought to give a good hint, if I can find the executable. Is there a better test? Thanks! bob prohaska > > > >> BUILD_ARCH should end up matching what > >> you start under, not the end target as > >> I understand things. > >> > >> 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.) > >> > >> That change is a local workaround that is > >> specific to the environment you are using > >> for a build. > >> > >> 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. > >> > >> I've not figured out what is going on (how/why) > >> for the != uname behavior that I observed. But > >> echoing the expected result instead did work. > >> > >> None of this is appropriate to check-in. > >> > >>> 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 > >> != 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: > >>> > >>>> It turns out that simply commenting out lines 447-452 in > >>>> /usr/src/Makefile.inc1 allows buildworld to run, even with > >>>> no /etc/make.conf in place. > >>> > >>> For reference: > >>> > >>> 447 .if make(buildworld) > >>> 448 BUILD_ARCH!= uname -p > >>> 449 .if ${MACHINE_ARCH} != ${BUILD_ARCH} > >>> 450 .error To cross-build, set TARGET_ARCH. > >>> 451 .endif > >>> 452 .endif > >>> > >>> (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.) > >>> > >>> > >>> I've had problems with Makefiles using != and uname > >>> ending up with the MACRO assigned being an empty string > >>> despite a command-line uname returning the expected > >>> text. > >>> > >>> 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): > >>> > >>> > >>> # Get the operating system type > >>> .if !defined(OPSYS) > >>> -OPSYS!= ${UNAME} -s > >>> +OPSYS!= echo FreeBSD > >>> .endif > >>> _EXPORTED_VARS+= OPSYS > >>> > >>> .if !defined(_OSRELEASE) > >>> -_OSRELEASE!= ${UNAME} -r > >>> +_OSRELEASE!= echo 12.0-CURRENT > >>> .endif > >>> _EXPORTED_VARS+= _OSRELEASE > >>> > >>> > >>> 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. > >> > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >