dlopen vs標準動態鏈接的用例是什麼？

Question

根據文檔，dlopen與dlsym一起使用來加載庫，並獲取指向符號的指針。

但是，這已經是動態加載器/鏈接器所做的。此外，這兩種方法都基於ld.so。

有實際上似乎使用dlopen時是兩個區別：

1. 庫可以有條件地加載。
2. 編譯器不知道我們正在使用的符號（類型，原型...），因此不檢查潛在的錯誤。順便說一句，這是實現自省的一種方式。

但是，這似乎並沒有激發了標準裝載使用dlopen，除了邊緣的例子：

1. 有條件的裝載是不是真的很有趣，在內存佔用優化方面當共享庫已被其他程序使用：加載已使用的庫不會增加內存佔用量。
2. 避免編譯器監督是不安全的，也是編寫錯誤的好方法......我們也忽略了潛在的編譯器優化。

那麼，有沒有其他的用途，其中dlopen是首選的標準動態鏈接/加載？

Answer 1

那麼，有沒有其他的用途，其中dlopen優先於標準的動態鏈接/加載？

典型的用例使用dlopen是

• 插件
• 選擇最佳執行當前CPU（英特爾數學庫這樣做）
• 選擇實現不同廠商的API（GLEW和其他的OpenGL包裝會這樣做）
• 延遲加載共享庫，如果它不太可能被使用（這會加速啓動，因爲庫構造函數不會運行+運行時鏈接呃將有略少的工作要做）

避免編譯監管是不安全的，寫錯誤的好辦法... 我們還缺少潛在的編譯器優化。

確實如此，但您可以通過在延遲加載的共享庫周圍提供一個小型包裝庫來獲得兩全其美的效果。在Windows上，這是通過標準工具完成的（谷歌的「DLL導入庫」），在Linux上你可以手工完成或使用Implib.so。

Answer 2

我在Windows環境中創建了語言切換功能。當我的應用程序啓動時，它會檢查配置設置應該使用哪個language.dll。從現在起，所有文本都從動態加載的庫中加載，甚至可以在運行時更換。我還包括格式化序號（第1，第2，第3），這是語言特定的功能。我的母語的語言資源包含在可執行文件中，所以我不能最終沒有任何文本。

關鍵是可執行文件可以在運行時決定應該加載哪個庫。在我的情況下，它是一種語言切換，或者正如評論員所說的那樣，像插件目錄掃描。

缺乏對呼叫簽名的監控顯然是一個缺點。如果你真的想做一些邪惡的事情，比如覆蓋原型類型定義，你可以用標準C類型轉換來實現。