Difficulty with armv6 to v7 transition.

[bob prohaska]

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 at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> >