作業系統開發 – 移值Linux的庫來我OS我的計劃

Linux下有很多不同的庫，
要把它們通通都移值去我OS是一個超大的任務，
有任務首先要有計劃，要用一個比較科學的方法去決定移值次序， 可以如下：

先移值最底層的庫，
但怎決定那一個庫是最底層呢？ 我搞了個小軟體可以查看各個庫的依賴情況，
它的原理很簡單， 就是查看在各個庫中ELF檔案格式的記錄，在ELF記錄中有一段是記錄這個庫和什麼庫作依賴。把/lib , /usr/lib, /usr/local/lib掃描一次就可以產生以下的一張“library
dependency chart"

在圖的左面你會看到Level 0, Level 1等等， 它代表第幾層，在右面你會看到很多不同的庫， 在同一層的庫， 它們會對下層的庫有依賴，箭頭所指的就是依賴(Dependency)。

這種技術也有它的缺點， 就是在靜態庫裡面根本沒有記錄依賴的資訊， 原因是"靜態"是不作dynamic linking的。但linux上大部分的庫也是動態庫，所有產生的依賴圖也是很準的了。 我用我的這個小軟體試了掃描很多不同的linux程式， 簡單的有三四層， 複雜的我見過有16,17層左右， 很少超過20層.

如果有兩個在相同層的庫， 我們應該怎決定先移植那一個先呢？ 我個人認為先取易舍難， 我們大可以掃描在庫中的ELF格式的symbol數量（重複的不計），就可以知道它用了它所依賴的庫的多少個函數，太約可以估計有移植這個庫有多複雜.

Linux世界是樹型結構

Linux世界是樹型結構，最底層的總是ld-linux.so和libc，可以證明C語言頂起了世界，令人驚奇的是C++語言在底層的重要性比我想像中要低很多，最起碼的就是standard
c++ library在最底幾層不見蹤影。所以說Linux底層是C++不正確。

移植次序

1)
先搞定libc，
這個無可置辦的，可以用newlib作為glibc的締代品， glibc過於巨型

2)
所有對libc只有單一依賴的庫，
意思是如果有一個庫， 它只對libc有所依賴，
先移植它們，
它們是libc, libc, zlib, libm, libpthread.
能提它們移過來， 就可以跑起busybox，
證明如下：

/root/download/busybox-1.20.2/_install/bin>readelf -a busybox |grep -i needed 0x00000001 (NEEDED)                     Shared library: [libm.so.6] 0x00000001 (NEEDED)                     Shared library: [libc.so.6]