"Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

* 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