On Tue, Apr 24, 2018 at 09:40:52AM +0100, Peter Humphrey wrote > > Anyway, this all leaves unanswered the question whether getting the > -march setting right in a chroot matters to the operation of the > chroot itself, as distinct from building good code for the target > machine. Personally, I can't see how it can have any such effect.
"-march" obviously has to match the target machine that the compiled code will run on. You have to run the query... gcc -c -Q -march=native --help=target | grep march= ...on the "target machine" to get the necessary value. That's true, regardless of whether the "target machine" is physical hardware, or a chroot, or a VM like QEMU/VMWare/etc. Things can get ugly in some edge cases if the final code (-march=<target_machine>) cannot run in the build environment (-march=<build_machine>). 1) Tests run at the end of the build, on the build machine, will obviously fail. 2) Pale Moon (and I assume Firefox as well) use the compiled code at the end of the build process to generate a precompiled startup cache. I ran into this when I was manually building Pale Moon, targetted for my Atom netbook, using my Core2 desktop as the build machine. The "bonnell" cpu (ancient 32-bit-only Atom variant) has an instruction set called "MOVBE" that the Core 2 does not. Hence, the bonnell-targeted code would fail on the Core2 with "illegal instruction" and other weird errors. This will also happen building for an AMD (with "3DNOW!" instructions) on an intel CPU. That's "solved" by adding... ac_add_options --disable-precompiled-startupcache ...to the mozconfig, preventing execution of that code in the build environment. The side effect is that the first time a profile is opened after an install or upgrade on an end-user machine, it takes somewhat longer, because it has execute the compiled code on the end-user machine to generate the cache. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
