我認爲在這個行業應該有一個最佳實踐,所以我在這裏問。連接EXE時厭倦了寫非直接.so,如何獲得救濟?
這個問題是關於使用Linux上的gcc將共享庫(.so)鏈接到可執行文件。但讓我從Windows開始。
假設我正在開發A.EXE,B.DLL,C1.DLL。的依賴性是
A -> B -> C1
這意味着:一個從B調用API,和B通過從C1調用API實現本身。 A不直接在C1中調用API。你知道,在鏈接A.EXE(使用Visual C++)時,我只需要列出B.lib(import lib)作爲A的鏈接組件(在makefile中);但是,如果鏈接組件在鏈接組件中, C1不必出現在A的makefile中。所以有一天我想用C2取代C1以更好地實現B,由於C1的替換,我不必更改A的makefile。
這很棒,因爲它遵循了理性思想:makefile只涉及與它直接相關的東西。有了這種便利,人們傾向於在Windows上編寫DLL而不是LIB--我認爲是這樣。
現在我轉向linux上的gcc。在相同的依賴的情況,在A的生成文件,我必須明確列出C1或C2爲紐帶組分,這樣的:
gcc -o A a1.o a2.o -lB -lC1
這麼折騰,想象你有十個項目A1,A2,... A10調用B,您必須修改10個makefile才能從C1切換到C2。
如何獲得解脫?
您沒有在Linux上的DLL 。你有共享對象庫,這是不同的野獸。 – 2013-02-25 08:00:31
謝謝。我提到Windows DLL只是因爲我需要引用我知道的預期行爲。 – 2013-02-25 08:42:06
但是,您需要了解(以及如何)'.so'文件在Linux上不像'.dll'在Windows上運行。 – 2013-02-25 08:43:06