Date: Wed, 7 Mar 2018 11:22:32 +0100 From: Christian Ullrich <chris@chrullrich.net> To: freebsd-stable@freebsd.org Cc: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>, Warner Losh <imp@bsdimp.com>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: "Cross" building for same architecture, different CPUTYPE Message-ID: <1e981716-bb44-e7d7-6be9-96b1f79d8da2@chrullrich.net> In-Reply-To: <20180305122207.GA37743@plan-b.pwste.edu.pl> References: <2126f358-c827-ecf0-109b-0488c5b155b6@chrullrich.net> <D30A88D2-6DFB-4535-8735-C71A43DEEB6B@FreeBSD.org> <CANCZdfqzZrjseYZybt%2BcDv5MLJEK5uZqtGvJCnPrLC6TNtBrJg@mail.gmail.com> <f24d5c35-2afe-1c88-c197-5d16dad80633@chrullrich.net> <20180305122207.GA37743@plan-b.pwste.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e981716-bb44-e7d7-6be9-96b1f79d8da2>