GCC：指定最小共享庫版本

Question

背景

我繼承和維護，這是非常緊密耦合與特定的硬件在Linux共享庫;我們稱之爲libfoo.so.0.0.0。這個圖書館已經存在了一段時間，並且「剛剛工作」。這個庫現在已經成爲多個高層應用程序的依賴關係。

現在，不幸的是，新的硬件設計迫使我用更寬的類型創建符號，從而導致libfoo.so.0.1.0。只有補充;沒有刪除或其他API更改。更新符號的原始縮小版本仍以原始形式存在。

此外，我有一個應用程序（說，myapp），取決於libfoo。它最初是爲支持庫的0.0.0版本而編寫的，但現在已被重新編寫以支持新的0.1.0 API。

爲了向下兼容的原因，我希望能夠通過編譯標誌爲舊庫或新庫構建myapp。給定版本的myapp將被加載的內核將始終只有一個版本的庫，在編譯時已知。

問題

這很可能libfoo將在未來再次更新。

1. 在構建myapp，是有可能指定最低版本的libfoo反對基於構建標誌鏈接？

2. 我知道可以直接在編譯CLI中指定庫名稱。這是否會導致myapp要求恰好爲該版本或將在相同主版本的更高版本的lib仍然能夠鏈接它（例如libfoo.so.0.2.0）？我真的希望在每次發佈新版次要版本時都不必更新每個依賴應用程序的內部版本。

3. 是否有一種更智能的方式來完成這與應用程序無關的方式？

參考

How do you link to a specific version of a shared library in GCC

Answer 1

你所描述外部庫版本，其中應用程序是針對libfoo.so.0，libfoo.so.1建等文檔here。

使用外部庫版本化要求正好libfoo.so.x的相同版本在運行時出現。

這通常是不在Linux，其中，通過symbol versioning魔力，允許單個libfoo.so.Y以提供相同符號的多個不兼容的定義，並且因此允許單個庫服務既舊的和正確的技術新應用程序同時。另外，如果您只是總是添加新符號，並且不以不兼容的方式修改現有符號，那麼沒有理由遞增外部版本。保留libfoo.so在版本0，提供一個int foo_version_X_Y;全局變量（以及所有以前的版本：foo_version_1_0,foo_version_1_1等），並讓應用程序二進制讀取它所需的變量。如果應用程序需要一個新符號foo_version_1_2，並且運行的舊庫僅提供foo_version_1_1，那麼應用程序將無法啓動並出現明顯錯誤。