I've run into a few situations where I've had to use "--disable-precompiled-startupcache". After some dead ends, I think I've found the root cause, and a solution. The following description is linux-centric with gcc, because that's all I use, but it may also apply to other OS/compiler pllatforms.
The bug... any cross-compiling situation where the target architecture code will not execute on the build architecture cpu will cause "mach package" to fai, unless "--disable-precompiled-startupcache" is invoked.
The root cause... (in linux at least) the packaging stage "mach package" executes "xpcshell"
ON THE BUILD MACHINE IN THE BUILD ENVIRONMENT to generate the precompiled startup cache. This explains everything.
- xpcshell compiled with "-march=amdfam10" will not run if built on my desktop Intel i5
- xpcshell compiled with "-march=bonnell" will not run in the 32-bit CentOS VM which directly uses my desktop's cpu
- xpcshell compiled with "-march=native" will work, by definition. Mind you, it's 6 hours and 15 minutes building on my Atom Netbook, even with "makeopts=-j3"
The bugfix... since xpcshell is only executed on the build machine, and is not packaged, let alone excuted on the target machine, it should be built with CFLAGS and CXXFLAGS set to "-O2 -march=native". This will work in the build environment, by definition. When grep'ing through the source, I see a lot of locations where CFLAGS and CXXFLAGS are set/modified. Setting CFLAGS/CXXFLAGS for the xpcshell code build, and re-setting them afterwards, looks like a fix that will work on both native and cross-compile builds. IANAP (I Am Not A Programmer) but this looks correct to me.