Date: Fri, 13 Oct 2017 22:47:06 -0700 From: bob prohaska <fbsd@www.zefox.net> To: mmel@freebsd.org Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm@freebsd.org, bob prohaska <bob@www.zefox.net> Subject: Re: Difficulty with armv6 to v7 transition. Message-ID: <20171014054706.GC75288@www.zefox.net> In-Reply-To: <39f6419f-48f3-aaec-dfa4-3048c8a893d8@freebsd.org> References: <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> <20171014021133.GB75288@www.zefox.net> <39f6419f-48f3-aaec-dfa4-3048c8a893d8@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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
> >>
> > _______________________________________________
> > 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"
> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171014054706.GC75288>