next up previous
Next: The minimum list of Up: Designing a Minimum System Previous: The Busybox vs. Standard

Libraries

Some of the library problems were mentioned above, glibc is a very large and powerful library, but for minimum systems it's a problem since it is very resource consuming. Nevertheless we stick with glibc, because reducing its size is not only complicated (you must figure out all function calls that are unused and remove them), but also because it poses a compatibility problem. If you try to optimize by modifying libraries, you lose compatibility with your desktop system. At the same time, it means maintaining a private version of the lib, and you don't want to maintain your own libc track!

Stripped libraries are dramatically smaller, and since debugging can comfortably be done on the desktop-system, there is no need to include debug symbols on MiniRTL. The same holds for executables that can be stripped, thereby massively reducing size. To reduce the number of required libraries, it is best to define a set of libraries for the minimum system and then strictly build on those. This is not such a big problem, due to the vast amount of software/sources on the Internet, it is quite easy to find editors, scripting languages and the like that will not need any special libraries. Naturally, the system will have a little bit of an archaic touch, but that's ok; you're not expected to work full time with ash and ae as your shell and editor. For administrative jobs, you can get used to it.



Subsections
next up previous
Next: The minimum list of Up: Designing a Minimum System Previous: The Busybox vs. Standard
Der Herr Hofrat
2002-03-08