使操作系統獨立的配置文件，檢查捲曲依賴

Question

我正在做一個configure.ac文件，檢查庫的依賴。

的完整源代碼，

AC_CONFIG_AUX_DIR([build-aux]) 

AC_INIT([myprogram], [0.1], []) 

AM_INIT_AUTOMAKE 

AC_PROG_CC 

AC_CHECK_LIB([curl], [curl_easy_setopt], [echo "libcurl library is present" > /dev/tty], [echo "libcurl library is not present" > /dev/tty]) 

AC_CHECK_LIB([sqlite3], [sqlite3_open], [echo "sqlite3 library is present" > /dev/tty], [echo "sqlite library is not present" > /dev/tty]) 

AC_CHECK_LIB([pthread], [pthread_create], [echo "pthread library is present" > /dev/tty], [echo "pthread library is not present" > /dev/tty]) 

AC_CHECK_LIB([crypto], [SHA256], [echo "crypto library is present" > /dev/tty], [echo "crypto library is not present" > /dev/tty]) 

AC_CONFIG_FILES([Makefile]) 

AC_OUTPUT 

「myprogram」是需要被安裝在衆多用戶pcs.So程序，依賴檢查需要開始時做的，找到這些是否安裝了四個庫。

在系統中，/usr/lib/i386-linux-gnu/libcurl.so在那裏，當我運行配置文件時，它給出消息「libcurl庫存在」。但是，在/usr/lib/i386-linux-gnu/libcurl.so.1.0或其他類似的系統中，它告訴libcurl不存在。如果我創建一個到libcurl.so的軟鏈接，那麼它正確地告訴libcurl存在。 ln -s /usr/lib/i386-linux-gnu/libcurl.so.1.0.0 /usr/lib/i386-linux-gnu/libcurl.so.Same也適用於其他庫。

其實，我想讓這個過程自動化。有沒有辦法做到這一點，而無需手動進行軟鏈接？我的意思是，通過對configure.ac文件本身進行更改，以便配置可以在任何機器上運行，而無需進行軟鏈接。

安裝庫時，安裝程​​序通常會創建一個從庫實名（libcurl.so.1.0.0）到其鏈接器名稱（libcurl.so）的符號鏈接，以允許鏈接器查找實際庫file.But並不總是正確的。有時它不會創建鏈接器名稱。這就是爲什麼會出現這些複雜情況。所以檢查鏈接器名稱的程序認爲該庫沒有安裝。

Answer 1

在系統中，/usr/lib/i386-linux-gnu/libcurl.so在那裏，當我運行配置文件時，它會給出消息「libcurl庫存在」。但是，在/usr/lib/i386-linux-gnu/libcurl.so.1.0或其他類似的系統中，它告訴libcurl不存在。

對，這是我期望的行爲。這裏發生的是AC_CHECK_LIB發出一個程序，其中包含您嘗試鏈接的符號（在本例中爲curl_easy_setopt），執行編譯步驟和鏈接步驟以確保鏈接程序可以鏈接。在典型的Linux發行版中，您需要確保安裝了一些名爲libcurl-dev（或類似的東西）的軟件包，以便安裝頭文件和libcurl.so符號鏈接。

但我想自動執行此過程。有沒有辦法做到這一點，而無需手動製作軟鏈接？所述libcurl-dev包的

安裝可以很容易地實現自動化。這可以通過幾種方式來完成，具體取決於你想怎麼做。 Linux包裝系統（例如rpmbuild，debhelper等）在構建之前可以引入構建依賴關係（如果未安裝它們）。用於設置生成計算機的配置管理工具（例如ansible，SaltStack等）可以安裝它。至少應該在發佈文檔中列出依賴關係，以便無權訪問這些工具（或不關心使用這些工具）的人可以找出並構建它們。

我不會在configure.ac中創建符號鏈接 - 它可能會破壞以後安裝的任何libcurl-dev。此外，你會有運行configure與提升特權（例如sudo）創建鏈接。

當安裝庫，安裝程序通常會從庫中創建的真實姓名（libcurl.so.1.0.0）與其連接器的名稱（libcurl.so）的符號鏈接允許鏈接找到實際的庫文件。但它並不總是如此。

實際上，我從未想過看到類似的東西。通常，當DSO安裝到ldconfig「受信任的目錄」（例如/usr/lib等）時，ldconfig會被運行，因此真正的庫（例如libcurl.so.1.0.0）會獲得一個符號鏈接（libcurl.so.1）目錄，但不包含開發符號鏈接（libcurl.so）。

編輯：添加答覆意見

但爲什麼還的./configure預計發展的符號鏈接S（libcurl.so，libcrypto.so等）

因爲configure可以告訴運行鏈接器，正如您在AC_CHECK_LIB中發現的那樣，如果這些符號鏈接不存在，鏈接將失敗。

配置檢查二進制文件是否可以在系統中運行，而不是是否可以構建使用這些庫的程序。

configure也有runtime測試以及編譯和鏈接時間檢測，因此它可以以一些有限的測試，如果編譯器的輸出可以運行。 configure的主要任務是確保安裝/配置先決條件，以便make可以正常工作，因此測試工具，標題，庫將以某種方式安裝並且以主要工作方式工作。運行時測試在某些環境（交叉編譯）中不起作用，所以許多軟件包不使用它們。

如果我沒看錯的，在./configure不能用於檢查二進制是否可以在一個系統上運行，因爲它是隻建立一個程序的情況下使用。

configure可以做的如在以上（例如AC_RUN_IFELSE）鏈路提到configure已建成的東西一些運行時的測試。

如果./configure成功，那麼二進制文件可以在機器上運行。 但是反過來是不正確的。也就是說，即使./configure失敗，二進制可能會運行，因爲它不依賴於開發符號鏈接（例如：libcurl.so）.Am我是對嗎？

你指的是哪個二進制文件？作爲AC_RUN_IFELSE的一部分創建的測試還是make的輸出？如果configure成功，則make的輸出仍可能無法工作。這就是make check的用途。如果configure失敗，則可能make將不起作用，並且您將無法進入可測試make輸出的部分。

如果場景是缺少libcurl。所以，並且configure未能鏈接AC_TRY_LINK測試，那麼同樣的鏈接步驟將如何爲您的可執行文件工作，因爲它也將依賴libcurl.so作爲鏈接步驟？它取決於該文件（僅用於鏈接步驟），因爲您可能安裝了多個libcurl.so.x庫。

通過二進制......我的意思是已經成功建立在以所有installed.What我說的是依賴一些其他的系統是二進制文件將在一臺機器上運行的程序，即使發展符號鏈接（libcurl中.so）不在那裏。

當然，它已經超越了鏈接步驟，並鏈接到了說libcurl.so.x以及它可能具有的任何其他依賴關係。