1 libtool的工作原理
libtool 是乙個通用庫支援指令碼，將使用動態庫的複雜性隱藏在統
一、可移植的介面中；使用libtool的標準方法，可以在不同平台上建立並呼叫動態庫。可以認為 libtool是gcc的乙個抽象，其包裝了gcc（或者其他的編譯器），使用者無需知道細節，只要告訴libtool需要編譯哪些庫即可，libtool 將處理庫的依賴等細節。libtool只與字尾名為lo、la為的libtool檔案打交道。
libtool主要的乙個作用是在編譯大型軟體的過程中解決了庫的依賴問題；將繁重的庫依賴關係的維護工作承擔下來，從而釋放了程式設計師的人力資源。 libtool提供統一的介面，隱藏了不同平台間庫的名稱的差異等細節，生成乙個抽象的字尾名為la高層庫libxx.la（其實是個文字檔案），並將該 庫對其它庫的依賴關係，都寫在該la的檔案中。該檔案中的dependency_libs記錄該庫依賴的所有庫（其中有些是以.la檔案的形式加入的）； libdir則指出了庫的安裝位置；library_names記錄了共享庫的名字；old_library記錄了靜態庫的名字。
當編譯過程到link階段的時候，如果有下面的命令：
$libtool --mode=link gcc -o myprog -rpath /usr/lib –l/usr/lib –la
libtool會到/usr/lib路徑下去尋找liba.la，然後從中讀取實際的共享庫的名字（library_names中記錄了該名字，比如 liba.so）和路徑(lib_dir中記錄了，比如libdir=』/usr/lib』)，返回諸如/usr/lib/liba.so的引數給激發出 的gcc命令列。
如果liba.so依賴於庫/usr/lib/libb.so，則在liba.la中將會有dependency_libs=』-l/usr/lib -lb』或者dependency_libs=』/usr/lib/libb.la』的行，如果是前者，其將直接把「-l/usr/lib –lb」當作引數傳給gcc命令列；如果是後者，libtool將從/usr/lib/libb.la中讀取實際的libb.so的庫名稱和路徑，然後組 合成引數「/usr/lib/libb.so」傳遞給gcc命令列。
當要生成的檔案是諸如libmylib.la的時候，比如：
$libtool --mode=link gcc -o libmylib.la -rpath /usr/lib –l/usr/lib –la
其依賴的庫的搜尋基本類似，只是在這個時候會根據相應的規則生成相應的共享庫和靜態庫。
2 為何使用 -wl,--rpath-link -wl,dir？
使用libtool解決編譯問題看上去沒什麼問題：庫的名稱、路徑、依賴都得到了很好的解決。但下結論不要那麼著急，乙個顯而易見的問題就是：並不是所有的庫都是用libtool編譯的。
比如上面那個例子，
$libtool --mode=link gcc -o myprog -rpath /usr/lib –l/usr/lib –la
如果liba.so不是使用libtool工具生成的，則libtool此時根本找不到liba.la檔案（不存在該檔案）。這種情況下，libtool只會把「–l/usr/lib –la」當作引數傳遞給gcc命令列。
考慮以下情況：要從myprog.o檔案編譯生成myprog，其依賴於庫liba.so（使用libtool生成），liba.so又依賴於 libb.so（libb.so的生成不使用libtool），而且由於某種原因，a對b的依賴並沒有寫入到liba.la中，那麼如果用以下命令編譯：
$libtool --mode=link gcc -o myprog -rpath /usr/lib –l/usr/lib –la
激發出的gcc命令列類似於下面：
gcc –o myprog /usr/lib/liba.so
由於liba.so依賴於libb.so（這種依賴可以用readelf讀liba.so的elf檔案看到），而上面的命令列中，並沒有出現libb.so，於是，可能會出現問題。
說「可能」，是因為如果在本地編譯的情況下，gcc在命令列中找不到乙個庫（比如上面的liba.so）依賴的其它庫（比如libb.so），鏈結器會按照某種策略到某些路徑下面去尋找需要的共享庫：
1. 所有由'-rpath-link'選項指定的搜尋路徑.
2. 所有由'-rpath'指定的搜尋路徑. '-rpath'跟'-rpath_link'的不同之處在於,由'-rpath'指定的路徑被包含在可執行檔案中,並在執行時使用, 而'-rpath-link'選項僅僅在連線時起作用.
3. 在乙個elf系統中, 如果'-rpath'和'rpath-link'選項沒有被使用, 會搜尋環境變數'ld_run_path'的內容.它也只對本地聯結器起作用.
4. 在sunos上, '-rpath'選項不使用, 只搜尋所有由'-l'指定的目錄.
5. 對於乙個本地聯結器,環境變數'ld_library_path'的內容被搜尋.
6. 對於乙個本地elf聯結器,共享庫中的`dt_runpath'和`dt_rpath'操作符會被需要它的共享庫搜尋. 如果'dt_runpath'存在了, 那'dt_rpath'就會被忽略.
7. 預設目錄, 常規的,如'/lib'和'/usr/lib'.
8. 對於elf系統上的本地聯結器, 如果檔案'/etc/ld.so.conf'存在, 這個檔案中有的目錄會被搜尋.
從以上可以看出，在使用本地工具鏈進行本地編譯情況下，只要庫存在於某個位置，gcc總能通過如上策略找到需要的共享庫。但在交叉編譯下，上述八種策略， 可以使用的僅僅有兩個：-rpath-link，-rpath。這兩個選項在上述八種策略當中優先順序最高，當指定這兩個選項時，如果鏈結需要的共享庫找不 到，鏈結器會優先到這兩個選項指定的路徑下去搜尋需要的共享庫。通過上面的描述可以看到：-rpath指定的路徑將被寫到可執行檔案中；-rpath- link則不會；我們當然不希望交叉編譯情況下使用的路徑資訊被寫進最終的可執行檔案，所以我們選擇使用選項-rpath-link。
gcc的選項「-wl,--rpath-link –wl,dir」會把-rpath-link選項及路徑資訊傳遞給鏈結器。回到上面那個例子，如果命令列中沒有出現libb.so，但gcc指定了「- wl,--rpath-link –wl,dir」，則鏈結器找不到libb.so的時候，會首先到後面-rpath-link指定的路徑去尋找其依賴的庫。此處我們使用的編譯命令的示例 是使用unicore平台的工具鏈。
$ unicore32-linux-gcc –o myprog /usr/lib/liba.so /
-wl,--rpath-link -wl,/home/unity_float/install/usr/lib
這樣，編譯器會首先到「/home/unity_float/install/usr/lib」下面去搜尋libb.so
libtool如何把選項「-wl,--rpath-link –wl,dir」傳遞給gcc？libtool中有乙個變數「hardcode_libdir_flag_spec」，該變數本來是傳遞「-rpath」 選項的，但我們可以修改它，新增我們需要的路徑，傳遞給unicore32-linux-gcc。
「hardcode_libdir_flag_spec」原來的定義如下：
hardcode_libdir_flag_spec="/$--rpath /$/$libdir"
我們修改後的定義如下：
hardcode_libdir_flag_spec="/$—rpath-link /$/$libdir /
-wl,--rpath-link -wl,/home/unity_float/install/usr/lib /
-wl,--rpath-link -wl,/home/unity_float/install/usr/x11r6/lib "
這樣，當libtool在「--mode=link」的模式下，就會把選項「-wl,--rpath-link –wl,dir」傳遞給gcc編譯器了。
libtool工作原理
libtool 是乙個通用庫支援指令碼，將使用動態庫的複雜性隱藏在統 一 可移植的介面中 使用libtool的標準方法，可以在不同平台上建立並呼叫動態庫。可以認為libtool是gcc的乙個抽象，其包裝了gcc 或者其他的編譯器 使用者無需知道細節，只要告訴libtool需要編譯哪些庫即可，libt...
KDevelop與libtool的問題
今天簡單嘗試了一下kdevelop這個ide，只想試一下 hello world 在新建完乙個輸出hello world的工程後，發現編譯不過 libtool line 1146 x.deps mytest.tpo no such file or directory 到網上搜尋了一下，看了下解決方法...
簡述hdfs工作原理 HDFS的工作原理
hdfs 的工作原理 hadoop 分布式檔案系統 hdfs 是一種被設計成適合執行在通用硬體上的分布式檔案系統。hdfs 是乙個高度容錯性的系統，適合部署在廉價的 機器上。它能提供高吞吐量的資料訪問，非常適合大規模資料集上的應用。要理解 hdfs 的內部工作原理，首先要理解什麼是分布式 檔案系統。...