我有一個圖書館X取決於圖書館Y.我有一個應用程序，其從X.調用函數C++鏈接的問題 - 動態與靜態庫的依賴關係
假設圖書館Y是僅提供靜態庫。如果X和Y都靜態鏈接到應用程序A，則一切正常。但是，我希望X是一個動態（共享）庫。
目前，具有A型連接器Y靜態不作爲動態X工作不能看到什麼是在Y.
有沒有什麼辦法讓Ÿ作爲一個動態庫，而無需靜態鏈接X到Y ？對Y進行包裝是不好的，以便我們有一個Y的動態版本。一般來說，是否有鏈接器選項可用於將Y（靜態鏈接到A）到X（動態庫）？
我想問的原因是我也有庫Z也取決於Y.我不想將Y靜態鏈接到X和Z，所以X和Z可以是動態的。
希望這不是太混亂。我感謝任何幫助。
嗯，這是相當簡單的靜態庫轉換成一個.so：
的gcc -shared library.a -oliblibrary.so
這是否解決？
正如你指出的那樣 - 如果你包裝了Y或者有一個動態Y，你的問題就可以解決了。
爲什麼你不能包裝Y使它動態？
爲什麼你不能得到一個動態的Y？
鑑於你不妥協的約束，你可能要爲Z和X的你基本上消除所有的選項鍊接Y ...
要編譯X的動態版本的靜態鏈接Y.然後應用程序只有鏈接X，並且對Y的使用沒有注意。無論你能否做到這一點，都會因平臺而異 - 我知道GCC和GNU鏈接器將允許它。問題是，編譯用作靜態庫的代碼和編譯用作動態庫的代碼並不相同;生成動態庫，以便它們可以重定位到任何內存區域（這使得它們可共享）。在Linux和Solaris上，這意味着使用「-fpic」指令編譯共享庫。如果在創建共享庫時發生PIC'd和非PIC'd代碼混淆（這是將Y靜態鏈接到X時會發生的情況），那麼您將收到有關未解析文本重定位的錯誤 - 這是鏈接器抱怨部分你的圖書館是無法比擬的。您可以通過傳遞-mimpure-text來禁用警告。但是，要意識到任何包含未使用「-fpic」編譯的代碼的頁面（因此任何包含對Y的調用的頁面）將不會在應用程序之間共享。因此，如果多個應用程序正在使用您的庫，它們將無法獲得通常使用共享庫所帶來的全部內存節省。如果這是你的平臺，那麼在Windows上可能有等效的標誌。
編輯：在我第一次閱讀沒有發現你的問題與Z.嘗試編譯X和Z與「-z undefs」，這樣GCC將忽略未定義的符號，然後當你鏈接你的應用程序確保Y是在X和Z之後的鏈接線（稍後的庫會填充在較早的庫中找到的參考文獻）。
感謝您的回覆。 不幸的是，我不允許觸摸靜態庫...它必須保持靜態庫。只是想知道是否可以以某種方式將靜態庫（鏈接到應用程序）暴露給動態庫。 – 2009-10-23 18:03:55
動態庫的符號在加載時解析...因此，動態加載的庫具有未定義的引用應該能夠解決針對您的應用程序的這些依賴關係。如果這有效，讓我知道，我會創建另一個答案。 – dicroce 2009-10-23 18:06:46