* 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!

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to