I've tested what would be the size saving when building glibc with -Os: $ du -h */*udeb 1020K normal/libc6-udeb_2.3.6-3_amd64.udeb 12K normal/libnss-dns-udeb_2.3.6-3_amd64.udeb 20K normal/libnss-files-udeb_2.3.6-3_amd64.udeb 888K tiny/libc6-udeb_2.3.6-3_amd64.udeb 12K tiny/libnss-dns-udeb_2.3.6-3_amd64.udeb 16K tiny/libnss-files-udeb_2.3.6-3_amd64.udeb For the udeb I think it's significant. I would suggest adding a build pass for -Os (and possibly other tinification options), and use that to prepare the udebs. What do you think? Would you like a patch for this?
Did you try if the result actually works? At least historically glibc was somewhat problematic when compiled with other than default optimisations. Thiemo
nptl and librt don't seem to like it: make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cond8.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-once3.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-once4.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-join5.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel4.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel5.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel9.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel17.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel22.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancel23.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx4.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx5.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx9.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx16.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx17.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx18.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx20.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cancelx21.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-cleanupx4.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-oncex3.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/nptl/tst-oncex4.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/rt/tst-mqueue8.out] Error 1 make[3]: *** [/tmp/glibc/glibc-2.3.6/build-tree/amd64-libc/rt/tst-mqueue8x.out] Error 1
Robert Millan wrote: Huh, I think I've checked whether -Os helped pretty much everything in d-i, but never thought to try libc. Good idea, and this space savings would in fact be useful; both because we're bursting at the seams of some of the smaller CD images, and because it would help keep d-i running in 32 mb of memory (assuming that the uncompressed sizes, which you didn't show, arn't suprising).
As you can see in the other mail, it seems to cause some breakage with nptl and librt. I'm not sure if d-i needs threading at all (or even what librt is ;). Is that an issue for libc-udeb ? If it is, perhaps we could patch nptl/librt code to add the proper -O option to override previous -Os. I think this could be accepted in upstream. Ah, I thought d-i already compressed them (e.g. cloop). Well, here is it: $ du -hs * 2.1M normal 1.8M tiny $ du -h */lib/*.so 100K normal/lib/ld-2.3.6.so 1.3M normal/lib/libc-2.3.6.so 24K normal/lib/libcrypt-2.3.6.so 12K normal/lib/libdl-2.3.6.so 540K normal/lib/libm-2.3.6.so 72K normal/lib/libpthread-2.3.6.so 80K normal/lib/libresolv-2.3.6.so 12K normal/lib/libutil-2.3.6.so 88K tiny/lib/ld-2.3.6.so 1.1M tiny/lib/libc-2.3.6.so 24K tiny/lib/libcrypt-2.3.6.so 12K tiny/lib/libdl-2.3.6.so 500K tiny/lib/libm-2.3.6.so 68K tiny/lib/libpthread-2.3.6.so 68K tiny/lib/libresolv-2.3.6.so 12K tiny/lib/libutil-2.3.6.so
Robert Millan wrote: Yes, I think that the graphical installer currently uses threads in at least one place.
tag 356735 + wontfix thanks All the tests have shown that the resulting packages are mostly broken, the level of brokeness, depending on the architecture and the version of the glibc. I am therefore tagging this bug as wontfix.
Should -Os be tested with gcc 4.2? Maybe it will work now.