與glibc和libstdc ++靜態鏈接

Question

我正在編寫一個與GNU GPL不兼容的跨平台應用程序。 我當前面臨的主要問題是該應用程序與glibc和libstdc ++動態鏈接，並且幾乎所有對庫的新更新都不向后兼容。 因此，在我的應用程序中會看到隨機崩潰。

解決方法是，將應用程序的二進制文件分發在幾個不同的系統（具有不同的C / C ++運行時版本）上編譯。 但我要沒有這個。 所以我的問題是，請牢記許可和所有注意事項，我可以靜態鏈接glibc和libstdc ++嗎？ 另外，這會導致rtld問題嗎？

Answer 1

不用了

將鏈接到的原始庫復制到應用程序文件夾中的目錄（在此示例中為../lib）。

喜歡：

my_app_install_path

1. .bin
2. LIB
3. 文件資料

重命名您的應用，例如app.bin。 用您的應用程序替換一個小的shell腳本，該腳本將環境變量LD_LIBRARY_PATH設置為庫路徑（並連接以前的LD_LIBRARY_PATH內容（如果有））。 現在，ld應該能夠找到鏈接到的動態庫，而無需將其靜態編譯為可執行文件。

請記住要遵守LGPL，將給定的屬性添加到庫中，並在文檔中指出可以下載源的位置。

Answer 2

glibc屬於LGPL。 在LGPL 2.1的第6節下 ，如果您遵循以下五個選項之一，則可以分發鏈接到該庫的程序。 第一種是提供庫的源代碼，以及您自己程序的目標代碼（源是可選的，不是必需的），以便可以將其與庫重新鏈接。 您也可以提供相同的書面報價。 您自己的代碼不必受LGPL約束，也不必發布源代碼。

libstdc ++在GPL之下，但有一個主要例外 。 基本上，您可以根據自己的選擇分配許可證，而不必提供自己的代碼或libstdc ++的源代碼。 唯一的條件是您可以正常編譯，而無需進行專有修改或GCC插件。

IANAL，如果您需要真正的法律建議，則應考慮咨詢一名。

Answer 3

如果為鏈接器指定選項-static-libgcc ，則會導致它鏈接到C庫的靜態版本（如果系統上可用）。 否則將被忽略。

Answer 4

我必須質疑您對糟糕的庫函數到底做了什么？

我也有一些跨平台軟件。 它可以在各種Linux系統上正常運行。 使用您要支持的最舊版本的軟件進行構建。 glibc和libstdc ++庫確實非常向后兼容。

我已經在CentOS 4上構建並在RHEL 6 beta上運行它。 沒問題。 我可以在穩定的Debian上構建並在測試中運行它。

現在，如果我嘗試建立在舊的Debian上並嘗試在CentOS 5.4上運行，有時我確實會對某些庫感到麻煩。 這通常是由於分發配置選擇不同，例如選擇線程還是非線程。