bug#311: -mcpu and ISO sizes

We've observed that the build environment and build host have a
substantial effect on the size of the generated ISO image -- producing
variations up to a million bytes!  For example, the nightly builds
produced by gar are around 48000000 bytes, where the result of
building on garson in a chroot with exactly the same source tree is
around 49000000 bytes, or around a 2% overall difference.

Nick and I looked at the individual binaries during the meeting today
and discovered that the chroot-built binaries on garson are typically
substantially larger than the equivalent binaries built on the native
environment on gar.  (Interestingly, some binaries, such as openssl,
are exactly the same size, down to the byte.  Most binaries, though,
appear to differ in size by a few percent.)

One hypothesis about this is that it has to do with the -mcpu flags
which are being passed to the compiler.  Some configure scripts or
Makefiles seem to run "arch" and then pass the equivalent of
-mcpu=$(shell arch) to gcc, causing it to generate code which is
optimized for that particular CPU.  (As Nick has pointed out, there is
also -march, which generates code which is optimized for that
particular CPU and might be incompatible with other CPUs.  -march is
used by at least one upstream packages, and we ought to purge it very
aggressively.)

The net result, in any case, is definitely individual binaries which
are different sizes depending on which machine they were built on.
The -mcpu discrepancy seems to be a plausible source of these
differences.  I ran a compile of a randomly chosen small program with
-Os -mcpu=i386 and again with the same source file and -Os -mcpu=i686
and immediately saw a difference of several hundred bytes (about 2% of
total file size).  The difference is in favor of -mcpu=i386 -- that is,
optimizing for an earlier CPU appeared to produce smaller code.

One relatively simple way to find all the places where -mcpu is used
by upstream packages' build scripts -- picking up on a recent idea of
Nate's -- would be to create a chroot with modified versions of the arch
and uname commands which always output "arrrrr" as the name of the
architecture (sc. arrrrrchitecture) of the host.  Then explicitly
architecture-dependent compile commands will all produce errors
immediately.

Indeed, I tried invoking gcc -Os -mcpu=arrrrr and got an error

cc1: bad value (arrrrr) for -mcpu= switch

The other workaround is to build everything on a 386, and just allot
a couple of weeks for every build.  (As a compromise, we could make
versions of arch and uname which report the architecture as "i386"
rather than "arrrrr".)

-- 
Seth David Schoen <[email protected]> | Reading is a right, not a feature!
     http://www.loyalty.org/~schoen/   |                 -- Kathryn Myronuk
     http://vitanuova.loyalty.org/     |