使用一个交替的c库
Newlib和dietlibc通过提供一个包装的脚本调用编译器使用正确的参数集，忽略包括在编译器中的标准c库，使用一个替换的c库。uClibc有点不同，它需要工具链。
一旦你知道如何调用GCC，接下来就要为项目更新Makefile文件或建立脚本，大多数情况下，为项目在Makefile文件中使用下面这样一行：
CC=CROSS_COMPILE-gcc
假如这样，所有用户都需要从命令行运行make命令覆盖CC变量：
make CC=dietc
这将导致makefile为c编译器调用diet，尽管看起来很诱人，不要在这个宏中添加参数，用CFLAGS变量代替，例如：
make CC="gcc -Os"
应该是：
make CC=gcc CFLAGS="-Os"
这个很重要，因为某些规则将调用CC编译，参数将没有意义，并会产生错误。
回到根文件系统
在选择了c库后，所有在根文件系统中的代码需要用新的编译器编译，那样代码就可以使用最近的、更小的c库。在这一点上，值得对静态与共享库进行评估，对于目标究竟该选择哪个，如果设备将运行任意的代码，而且在部署时该代码是未知的，共享库是最好的选择。如：设备可能暴露一个API允许最终用户或专业工程师编写模块。假如这样，设备上的库应该为这些新特征实现提供最大的灵活性。
如果系统包括许多分隔的程序共享库也是最佳的选择，假如这样，共享代码的拷贝将比复制几个文件的相同代码更小。
当只有几个程序在使用时，最佳做法是为每种用途创建一个系统然后比较最后的大小，大多数情况下，较小的系统是没有共享库的，而且还有一个额外的受益，没有共享库的系统载入和启动程序时更快（因为没有连接这一步了），因此用户从效率角度来说也受益了。
总结
尽管没有象魔术一样的工具使系统变得更小，但也不缺少工具帮助使系统仅可能变得更小，而且，使Linux变小比减小内核大小更困难，根文件系统需要严格检查，因为这个部件比内核消耗得更多空间，本文主要叙述了可执行映像大小，减少运行中程序内存需求。
