那么又如何控制可執行文件的大小呢？除了卻除軟件中不需要的部份外，我們還應該考慮軟件所引用的庫文件。GNU的Glibc是一個非常寵大而完整的庫，至少對于嵌入式系統來說，其體積顯得過于大了一些。uClibc的提出較好的解決了這樣一個問題。uClibc盡可能的兼容Glibc，大多數應用程序可以在很小或完全不修改的情況下就可能使用uClibc替代glibc。通過uClibc來代替Glibc，可以在不改變應用程序功能的前提下，大大減少發布文件的大小，無論應用程序以靜態鏈接來編譯，還是以動態鏈接形式編譯。
不過使用uClibc代替并不是簡單的設置一兩個參數就行了，通常需要使用一個不同的工具集(gcc/binutils等)來編譯代源碼。手工的構造這樣一個環境，對于大多數普通程序員來說，不一定是一件很簡單的事情，因此，uClibc的開發者創造出一個叫做buildroot的工具集。 buildroot將自動構造編譯基于uClibc代碼的工具集和uClibc庫，并提供一個可配置的框架和一些構建一個基本系統的配置文件。用戶只需要通過配置菜單選擇了相應的目標軟件，buildroot就可以從構建基本工具集開始，一直到最后構建出目標系統所需要的東西，如嵌入式系統常用的基于 ext2的initrd，jffs根文件系統，壓縮的根目錄樹等，這些代碼都是基于uClibc而不是系統的Glibc的。Buildroot對主機系統的要求較小，通常只需要主機系統提供足以構建工具鏈(toolchain)的工具，如gcc/binutils等，當工具鏈編譯完成后，對目標系統需要的源碼的編譯過程與主機系統的開發工具集基本上就沒有什么關系了。因此，不同的主機如果能夠通過第一步，編譯完成工具鏈，那么編譯出來的目標系統的執行代碼就可以幾乎不存在由于系統引起的差異。這樣，開發人員就可能在各自喜歡的Linux發行版上進行開發，而不必擔心出現什么兼容性問題。
uClinux
uClinux與emDebian至少有兩個重要的區別，第一是構建方式，前面已經提到過了，uClinux屬于 from scratch 一類的。另一個不同的地方，uClinux是支持不在emDebian支持的11種CPU的，當然，這個說法不是很恰當，正確的說法是uClinux支持那些不具備MMU單元的CPU體系。uClinux的第一個目的是支持MC68328芯片，現在已經能構支持更多的CPU，如Intel i960，ARM等。不過，uClinux的主體開發團隊目前已經不再支持ARM了，還好 Samsung 的 Hyok S. Choi 接過了接勵棒，Linux 2.6版本的補丁可以在 uClinux/ARM2.6 找到。
uClinux之前僅是核心的一些補丁，后來發展成為一個包括核心、庫、應用程序、工具和編譯相關的配置文件的一個集成開發環境。與 buildroot不同的是，uClinux不編譯目標系統的工具集，也就是說，相應的編譯工具應該提前安裝好。如，對于arm來說，需要先安裝ARM交叉編譯器。uClinux的編譯器也需要一些補丁，其中比較重要的兩個方面主要包括：