* Marek Zarychta wrote:
* Warner Losh wrote:
I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do
these sorts of things. CPUTYPE is known to only work on native builds
Maybe you should try to build using different make.conf(5) files for
each build? It can be improved WITH_META_MODE=YES enabled in
src-env.conf (requires loading filemon(4) first) and two differnt object
Thanks for the hint. While experimenting with it, I found the --
somewhat obvious, in hind sight -- solution.
The source of the trouble is the build system's installed
/usr/lib/libc.a, which the /usr/src/tmp binaries are linked against, as
well as some few other things.
The fix is to have a world on the build system that is built without any
CPUTYPE setting, so that the compiler only uses the original amd64
instruction set; that goes up to SSE2. An actual "distribution"
buildworld can then use any CPUTYPE that the intended target supports.
A workaround, at least for upgrading from 11.1 to stable/11, is to
remove the /usr/obj/usr/src/tmp directory entirely, so that
installkernel and installworld use the tools on the target system. It
worked for me, but is probably not entirely reliable.
I still think there is an argument to be made for avoiding this kind of
potential breakage in "near cross" builds, but it is probably not worth
the extra effort during buildworld (rebuild, or at least relink,
/usr/src/tmp etc. against the freshly made libc.a).
The "few other things" above are, by the way:
- usr.bin/mkesdb_static
- usr.bin/mkcsmapper_static
- rescue
The first two are not installworld'ed, so I wonder why they are where
they are, and the last one is a cruel, cruel thing to do.
Thanks for your help!
--
Christian
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
