我正在構建從應用程序（我無法控制）加載的共享庫。我的圖書館使用其他共享庫，而這些共享庫反過來使用其他共享庫，但是並不罕見。Linux，共享庫使用主程序中的函數而不是其他共享庫
的問題是，所述主應用程序具有本功能，在庫中的鏈進一步向下的一個，更具體是openLDAP，反過來使用openSSL功能：
Main app->My library->openLDAP libraries->openSSL libraries
我的猜測是主要應用是通過靜態鏈接或簡單的複製/粘貼源代碼來實現openSSL。
我的問題是：我可以控制openLDAP從我的庫中使用哪些函數，還是必須使用靜態鏈接重新編譯openLDAP到openSSL？
由於openSSL由於安全問題而相當頻繁地更新，如果我不需要，我不想要它的靜態副本。以及爲什麼當openLDAP是大多數發行版包的一部分時重新發布openLDAP的專有副本...
的解決辦法是在dlopen的使用RTLD_DEEPBIND（3）：
RTLD_DEEPBIND（因爲glibc的2.3.4）的符號在這個庫中的查找範圍提前 全球範圍內的
廣場。這意味着一個自包含的庫將使用其自己的符號優先於包含在已加載的庫中的全局符號 。該標誌不是POSIX.1-2001中規定的 。
這可能不是最好的解決方案，但它在此過程由閉源軟件創建時適用。
現在，您擁有的是可執行文件，覆蓋了否則系統默認選擇OpenSSL庫的可執行文件。在可執行文件的權限範圍內，你不能真正阻止它。
靜態鏈接庫中的OpenSSL可能也不是真正的解決方案。首先，如果可執行文件確實會使用不同的版本呢？另一方面，如果OpenSSL有一些全局變量呢？現在，您將在同一個進程中擁有兩個庫，這不是一個好主意，可能會導致錯誤。
對我而言，我們在Linux上的最佳答案是不考慮這種事情是一個問題。如果一個可執行文件加載了一個不好的OpenSSL版本，那不是你的庫的錯。至多你可以檢查哪個版本被加載，如果出於某種原因已知與你的庫不兼容，則拒絕運行。
我的猜測是，主要的應用是通過靜態鏈接或源代碼的簡單的複製/粘貼OpenSSL的實施既 。
這是錯誤的事情。如果應用程序開發者在他的腳上射擊，那麼你不能做任何事情。
應用程序開發人員應該看到，你的庫依賴於OpenSSL庫（使用LDD命令），那麼他不應該鏈接OpenSSL again as staticly or copy paste its code.
如果從OpenSSL的一些功能，不造成任何混亂的，如果他們可以只用像任何任何Java類的靜態方法，那麼只有App開發人員應該承擔在應用程序中實現該代碼的風險。
我用Mozilla NSS而不是openSSL構建了openLDAP。這樣我就不會做任何尷尬的事情，並試圖解決別人的錯誤。 – Tobias 2014-10-15 05:38:21