#名稱

ExtUtils::Liblist - 判斷要使用的函式庫及其使用方式

#語法

require ExtUtils::Liblist;

$MM->ext($potential_libs, $verbose, $need_names);

# Usually you can get away with:
ExtUtils::Liblist->ext($potential_libs, $verbose, $need_names)

#說明

此工具採用 -llib1 -llib2 -llib3 形式的函式庫清單，並傳回適合包含在延伸模組 Makefile 中的行。額外的函式庫路徑可以使用 -L/another/path 形式包含，這會影響後續所有函式庫的搜尋。

它會傳回包含四或五個純量值的陣列：EXTRALIBS、BSLOADLIBS、LDLOADLIBS、LD_RUN_PATH，以及實際函式庫檔名的陣列參考（如果有的話）。其中一些在 Unix 上才有意義。請參閱下方關於這些平台特定部分的詳細資料。函式庫檔名的清單僅在 $need_names 參數為 true 時傳回。

相依函式庫可以使用三種方式之一連結

對於靜態延伸模組

當 Perl 二進位檔與延伸模組函式庫連結時，由 ld 指令連結。請參閱下方的 EXTRALIBS。
針對建置/連結時間的動態擴充套件

在建置/連結共用物件時，由 ld 指令執行。請參閱下方的 LDLOADLIBS。
針對載入時間的動態擴充套件

在載入共用物件時，由 DynaLoader 執行。請參閱下方的 BSLOADLIBS。

#EXTRALIBS

連結包含此擴充套件的 Perl 二進位檔時，需要連結的函式庫清單。僅包含實際存在的函式庫。這些函式庫會寫入檔案，並在連結 Perl 時使用。

#LDLOADLIBS 和 LD_RUN_PATH

使用 ld 建立時，可以或必須連結到共用函式庫的函式庫清單。這些可能是靜態或動態函式庫。LD_RUN_PATH 是 LDLOADLIBS 中目錄的冒號分隔清單。它會作為環境變數傳遞給連結共用函式庫的程序。

#BSLOADLIBS

需要但可以在執行時間動態連結的函式庫清單。SunOS/Solaris 不需要此功能，因為 ld 會將資訊（來自 LDLOADLIBS）記錄到物件檔案中。此清單用於建立 .bs（開機）檔案。

#可攜性

此模組處理許多系統相依性，且程式碼中有相當多特定於架構的 if。

#VMS 實作

在 VMS 下執行的 ext() 版本與 Unix-OS/2 版本在幾個方面有所不同

接受輸入函式庫和路徑規格，有或沒有 Unix 連結器使用的 -l 和 -L 前置詞。如果兩個前置詞都不存在，則如果令牌實際上是一個目錄，則會將其視為要搜尋的目錄，否則會將其視為要搜尋的函式庫。希望其擴充套件可攜至 Unix 或 OS/2 的作者應使用 Unix 前置詞，因為 Unix-OS/2 版本的 ext() 需要它們。
在可能的情況下，共用映像優先於物件函式庫，而物件函式庫優先於純物件檔案。根據 VMS 命名慣例，ext() 會尋找名為 libshr 和 librtl 的檔案；它也會尋找 liblib 和 liblib 以適應某些移植軟體中使用的 Unix 慣例。
對於找到的每個函式庫，都會產生連結器選項檔案的適當指令。傳回值是這些指令的空白分隔字串，而不是連結器命令列中使用的元素。
LDLOADLIBS 包含根據 $potential_libs 找到的函式庫和 Config.pm 中指定的 CRTL（如果有）。EXTRALIBS 僅包含根據 $potential_libs 找到的函式庫。BSLOADLIBS 和 LD_RUN_PATH 永遠是空的。

此外，還會嘗試辨識幾個常見的 Unix 函式庫名稱，並根據需要將其篩選出來或轉換為 VMS 等效名稱。

一般來說，ext() 的 VMS 版本應該可以適當地處理原本設計給 Unix 或 VMS 環境的擴充套件輸入。如果您遇到問題，或發現可以改善搜尋的案例，請讓我們知道。

#Win32 實作

在 Win32 下執行的 ext() 版本在幾個方面與 Unix-OS/2 版本不同

如果 $potential_libs 為空，傳回值也會為空。否則，由 $Config{perllibs}（請參閱 Config.pm）指定的函式庫會附加到 $potential_libs 的清單中。系統會在 $potential_libs、$Config{libpth} 和 $Config{installarchlib}/CORE 中指定的目錄中搜尋函式庫。對於找到的每個函式庫，系統會產生一個以空白分隔的完全限定函式庫路徑名稱清單。
輸入函式庫和路徑規格可以接受 Unix 連結器使用的 -l 和 -L 前綴，也可以不接受。

-La:\foo 形式的項目會指定 a:\foo 目錄來尋找後面的函式庫。

-lfoo 形式的項目會指定函式庫 foo，其拼寫方式可能會根據您使用的編譯器類型而有所不同。如果您使用的是 GCC，它會轉換成 libfoo.a，但對於其他 win32 編譯器，它會變成 foo.lib。如果使用這些轉換名稱找不到任何檔案，系統會再嘗試使用 foo.a 或 libfoo.lib 來尋找，具體取決於使用的編譯器是 GCC 還是其他 win32 編譯器。

如果項目中沒有 -L 或 -l 前綴，則該項目會被視為目錄（如果它實際上是目錄）或函式庫（否則）來搜尋。$Config{lib_ext} 字尾會附加到任何不是目錄且尚未有該字尾的項目。

請注意，不需要 -L 和 -l 前綴，但希望其擴充套件可以移植到 Unix 或 OS/2 的作者應該使用這些前綴，因為 ext() 的 Unix-OS/2 版本需要這些前綴。
項目不能是純物件檔案，因為許多 Win32 編譯器不會處理函式庫中的物件檔案。
$potential_libs 中以冒號開頭且後接字母數字字元的項目會被視為旗標。系統會忽略未知的旗標。

符合 /:nodefault/i 的項目會停用附加在 $Config{perllibs} 中找到的預設函式庫（這應該很少需要用到）。

符合 /:nosearch/i 的項目會停用對其後指定的函式庫的所有搜尋。-Lfoo 和 -lfoo 的轉換仍會適當地發生（根據使用的編譯器而定，如 $Config{cc} 所反映），但不會驗證這些項目是否為有效的檔案或目錄。

符合 /:search/i 的項目會重新啟用對其後指定的函式庫的搜尋。您可以將它放在最後，以啟用對由 $Config{perllibs} 指定的預設函式庫的搜尋。
指定的函式庫可以是靜態函式庫和匯入函式庫（與 DLL 連結）的混合。由於這兩種函式庫在 Win32 平台上都以相當透明的方式使用，因此我們不會嘗試區分它們。
在 Win32 中，LDLOADLIBS 和 EXTRALIBS 始終相同，而 BSLOADLIBS 和 LD_RUN_PATH 始終為空（這可能會在未來發生變化）。
如果您必須確保任何路徑和路徑組件都正確地用雙引號包圍，如果它們包含空格。例如，$potential_libs 可以是（實際上）
```
"-Lc:\Program Files\vc\lib" msvcrt.lib "la test\foo bar.lib"
```
請注意，第一個和最後一個條目都用引號保護，以保護空格。
由於此模組最常僅從擴充套件 Makefile.PL 檔案間接使用，以下是 Makefile.PL 條目範例，用於將函式庫新增到擴充套件的建置程序
```
LIBS => ['-lgl']
```
使用 GCC 時，該條目指定 MakeMaker 應首先在 $Config{libpth} 指定的所有位置中尋找 libgl.a（後跟 gl.a）。

使用 GCC 以外的編譯器時，上述條目將搜尋 gl.lib（後跟 libgl.lib）。

如果函式庫碰巧位於不在 $Config{libpth} 中的位置，您需要
```
LIBS => ['-Lc:\gllibs -lgl']
```
以下是一個較少使用的範例
```
LIBS => ['-lgl', ':nosearch -Ld:\mesalibs -lmesa -luser32']
```
這指定如前所述搜尋函式庫 gl。如果該搜尋找不到函式庫，它會查看清單中的下一項。:nosearch 旗標將防止搜尋後續函式庫，因此它僅將值傳回為 -Ld:\mesalibs -lmesa -luser32，因為 GCC 可以使用該值作為連結器。

使用 Visual C 編譯器時，第二個項目會傳回為 -libpath:d:\mesalibs mesa.lib user32.lib。

使用 Borland 編譯器時，第二個項目會傳回為 -Ld:\mesalibs mesa.lib user32.lib，而 MakeMaker 會負責將 -Ld:\mesalibs 移到連結器命令列中的正確位置。

#另請參閱

ExtUtils::MakeMaker