freebsd stable - Mar 2018 - "Cross" building for same architecture, different CPUTYPE

On 4 Mar 2018, at 18:29, Christian Ullrich <chris at chrullrich.net>
wrote:
> 
> I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel
Atom CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build machine.
That works fine, but make installkernel on the Atom box fails with a SIGILL
(signal 4) in the "install" command (sorry, no log or screenshot).
> 
> As far as I can tell, this is because installkernel uses the install from
...obj.../tmp/legacy/usr/bin, which is built for the host. Disassembling the
binary shows that it uses AVX opcodes. The "main" part of the build
output correctly respects the CPUTYPE override.
How are you overriding?  As far as I know, the bootstrap-tools are built
using NO_CPU_CFLAGS, which disables any cpu-specific CFLAGS.  However,
this does not work in two cases:

1) If you assign CPUTYPE with = instead of ?= (in make.conf or src.conf)
2) If you set -march= flags in CFLAGS directly

With 1), if you specify CPUTYPE= as a variable directly on the make
command line, it will effectively disable NO_CPU_CFLAGS.

> I suppose I'm doing something wrong here, but what? It must be possible
to build for a different CPU of the same family, right? I even tried running a
cross build (TARGET=amd64 TARGET_ARCH=amd64), but since the build host _is_
amd64, the Makefiles laughed at me and only did the normal build.
> 
> The command that did not work was:
> 
> MAKEOBJDIRPREFIX=/usr/obj/slm make CPUTYPE=slm buildworld buildkernel
> 
> I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here.
Actually, that *is* relevant for the stages after bootstrap-tools,
build-tools and cross-tools.  E.g. 4.x and later.

Again, this depends on how exactly you are overriding CPUTYPE.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180304/43b1c508/attachment.sig>

On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric <dim at freebsd.org>
wrote:
> Again, this depends on how exactly you are overriding CPUTYPE.

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 and
is tricky to do in this scenario just so. It might work for 'near cross'
builds, or it might not. TARGET_CPUTYPE overrides CPUTYPE that might be set
in weird places and generally works a lot better. You don't need to set
TARGET or TARGET_ARCH to do this, but it would work if you did that also.

Warner

* Dimitry Andric wrote:
> On 4 Mar 2018, at 18:29, Christian Ullrich <chris at chrullrich.net>
wrote:
>> I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant
here.
> 
> Actually, that *is* relevant for the stages after bootstrap-tools,
> build-tools and cross-tools.  E.g. 4.x and later.
> 
> Again, this depends on how exactly you are overriding CPUTYPE.
Thank you for the explanation, Dimitry. As I wrote, I have the host's 
native CPUTYPE in make.conf (CPUTYPE?=core-avx2) and the target on the 
command line (make CPUTYPE=slm buildworld buildkernel).

Since my previous e-mail, I actually had the bright idea of removing 
.../tmp/legacy/usr/bin/install, and that let the installkernel succeed.

My previous assumption that the remainder of the build obeyed the 
override must have been wrong, though, because installworld failed in 
strip for /lib/libc.so.7, and after that, nothing worked anymore.

Perhaps I should get a non-x86(_64) build host and really do a full 
cross build ...

Thanks again,

-- 
Christian