Iguleder's Blog

A few days ago I rebuilt the whole Calf GNU/Linux from scratch, with the most recent packages, with two exceptions:

• GCC 4.4.4 instead of 4.5.0; the latter was reported to produce much larger binaries and Mozilla said it had some regressions.
• The kernel headers glibc was built against are the 2.6.27.48 headers and that is the minimum kernel the system can run with. I picked this version because as a Puppy user and developer, I want Calf to be compatible with a “retro” kernel (as Puppy users call it). The 2.6.27.x is the current long-term support branch, so 2.6.27.48 is the best candidate for a second kernel for Calf.

Today I repeated the whole procedure percisely, step-by-step. However, for some reason, there is some difference in binary size between both builds – all the binaries of the second build are slightly bigger, despite of the fact both builds are identical … well, except two things: in the second build I added “-pipe” to the compiler flags and enabled an extra option when I compiled GCC: “–with-system-zlib”.

I examined various pieces of relevant documentation to find out the reason for this difference. The “-pipe” flag is described by the GCC man page as the following:

-pipe
Use pipes rather than temporary files for communication between the various stages of compilation.  This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.

All compilation passed just fine and I use the GNU assembler, the Binutils as. This means the flag is harmless, at least in my situation; it cannot affect the binary size. Instead, it should make the compilation faster and that’s all should do.

However, this is the Linux From Scratch description of the GCC option I enabled (the typo is included in the price):

–with-system-zlib
This switch tells GCC to link to the system installed copy of the Zlib library, rather than its own internl copy.

That leaves me with a conclusion: the use of the external zlib must be responsible for this. It’s weird, I don’t think it has anything to do with binary size, unless the binary has an some sort of runtime decompression built-in, as in binaries that passed through UPX.

That’s weird and annoying, but I’ll have to live with that. The fact that 4.5.0 can’t beat this great (but not perfect) result is very satisfying already, so I’m not worried.

EDIT: I finished all compilation and it seems that some stuff are actually smaller. One glibc library was 9 MB instead of about 0.5 MB; I stripped it and the final size is around 400 KB … that’s totally weird.