When Tribblix boots from the installation ISO, it reads in two things: the root archive, as a ramdisk, and /usr mounted from solaris.zlib via lofi.
In preparation for the next update, I've spent a little time minimizing both files. Part of this was alongside my experiments on genuinely memory-constrained systems; working out what's necessary in extreme cases can guide you into better behaviour in normal circumstances. While I don't necessarily expect installing onto a 128M system to be a routine occurrence, it would be good to keep 1G or even 512M within reach.
One of the largest single contributors to /usr was perl. It turns out that the only critical part of the system that needs perl is intrd, which is disabled in the live environment anyway. So, perl's not needed.
Another significant package is GNU coreutils. On closer investigation, the only reason I needed this was for a script that generated a UUID which is set as a ZFS property on the root file system (it's used by beadm to match up which zone BE matches the system BE). Apart from the fact that this functionality has recently been integrated into illumos, using the GNU coreutils was just being lazy (perhaps it was necessary under Solaris 10, where this script originated, but the system utilities are good enough now).
I also had the gcc runtime installed. The illumos packages don't need it, but some 3rd-party packages did - compile with gcc and you tend to end up with libgcc_s being pulled in. There are a variety of tricks with -nostdlib and -static-libgcc that are necessary to avoid this. (And I wish I understood better exactly what's happening, as it's too much like magic for my liking.)
The overall impact isn't huge, but the overall footprint of the live image has been reduced by 25%, which is worthwhile. It also counteracts the seemingly inevitable growth of the base system, so I have to worry less about whether I can justify every single driver or small package that might be useful.
3 comments:
You might be able to solve the libgcc_s issue by delivering the runtime like SUNWgcc-runtime (or was it SUNgccruntime?) solved it. Or you might not need libgcc_s at all:
http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
GCC's dirty secret is that libgcc_s is actually completely unnecessary when linking C programs -- libgcc_s gets linked in as an exception handler when linking C++ programs. I have built C executables without libgcc_s, and they worked just fine.
The runtime already is a separate package. The aim here was to make sure that I didn't need it on the live image.
By default, libgcc_s gets pulled in pretty often. It's clearly not necessary for well written software using a sane build system (illumos is built with gcc and doesn't suffer from this problem, for example). But the magic runes to fix the problem vary quite a bit between packages, and between shared libraries (which is the real problem) and final binaries, and feeding it through some half-baked asinine build system is a joyous exercise (people can probably guess what I'm referring to here). Not.
The tricky one here turned out to be trousers, it took me several attempts to get that rebuilt in such a way that it didn't break java and/or ssh.
So you actually did manage to ditch the libgcc_s linkage? If so, that's pretty sweet!
Post a Comment