Date: Fri, 13 Oct 2017 19:11:33 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <markmi@dsl-only.net> Cc: freebsd-arm@freebsd.org, bob prohaska <bob@www.zefox.net> Subject: Re: Difficulty with armv6 to v7 transition. Message-ID: <20171014021133.GB75288@www.zefox.net> In-Reply-To: <254A2C41-59A9-4E4E-8982-ADDBAE2B5F91@dsl-only.net> References: <1507573171.84167.9.camel@freebsd.org> <20171011023356.GA57571@www.zefox.net> <CANCZdfrKYabu1-bWxX47=Lt=33e%2BFjBXCNBNiGPE7K-83KOAHA@mail.gmail.com> <CANCZdfqHfAe24q=6n8CxsHQv24j58bQLPG3z_7vi_xpGjdQzDg@mail.gmail.com> <20171011030021.GB57571@www.zefox.net> <20171013020604.GA70845@www.zefox.net> <20171013175943.GA74121@www.zefox.net> <F9F4D731-35CD-44E6-8419-D73CB98655E9@dsl-only.net> <20171014010713.GA75288@www.zefox.net> <254A2C41-59A9-4E4E-8982-ADDBAE2B5F91@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 13, 2017 at 06:27:22PM -0700, Mark Millard wrote:
> On 2017-Oct-13, at 6:07 PM, bob prohaska <fbsd@www.zefox.net> wrote:
>
> > Seems it would have been better to replace
> > BUILD_ARCH!= uname -p
> > with
> > BUILD_ARCH!= echo armv7
> > for present purposes.
>
> Are you starting under armv6 ? armv7 ?
I'm afraid it's a mix, due to some untimely foot-shooting.
Uname - p reports armv7, but clang -v reports
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: armv6-unknown-freebsd12.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
I'll keep trying to unscramble the mess I've made until an armv7 RPI2
snapshot is released, then start over if necessary.
Thanks for reading!
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 <fbsd at www.zefox.net> 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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171014021133.GB75288>