CMP0060

警告

此策略的 OLD 行為已在 CMake 4.0 版本中移除。此策略必須透過呼叫 cmake_minimum_required()cmake_policy() 設定為 NEW

在 3.3 版本中新增。

即使在隱含目錄中,也依完整路徑連結程式庫。

策略 CMP0003 的引入目的是在將完整路徑給予 target_link_libraries() 命令時,始終依完整路徑連結程式庫檔案。然而,在某些平台(例如 HP-UX)上,編譯器前端會為目前的架構新增替代的程式庫搜尋路徑(例如,/usr/lib/<arch> 具有 /usr/lib 中程式庫的替代方案,適用於目前的架構)。在這些平台上,find_library() 可能會找到一個程式庫,例如 /usr/lib/libfoo.so,該程式庫不屬於目前的架構。

在策略 CMP0003 之前,專案在這種情況下仍然可以建置,因為不正確的程式庫路徑會在連結行上轉換為 -lfoo,而連結器會在編譯器前端隱含提供的架構特定搜尋路徑中找到正確的程式庫。當時,我們選擇保持與這些專案的相容性,方法是始終將在隱含連結目錄中找到的程式庫檔案轉換為 -lfoo 標記,以要求連結器搜尋它們。這種方法允許現有專案繼續建置,同時仍然透過完整路徑(例如建置樹中的那些)連結到隱含連結目錄之外的程式庫。

CMake 確實允許專案透過使用 IMPORTED 程式庫目標 並將其 IMPORTED_LOCATION 屬性設定為程式庫檔案所需的完整路徑,來覆寫此行為。事實上,許多 Find Modules 正在學習提供 Imported Targets,而不是僅僅提供傳統的 Foo_LIBRARIES 變數來列出程式庫檔案。然而,這使得由 Find Module 找到的程式庫所產生的連結行,取決於它是否透過匯入的目標連結,這是不一致的。此外,這種行為一直是混淆的根源,因為程式庫檔案的產生連結行取決於其位置。對於嘗試靜態連結的專案來說,這也是有問題的,因為像 -Wl,-Bstatic -lfoo -Wl,-Bdynamic 這樣的標記可以用於幫助連結器選擇 libfoo.a 而不是 libfoo.so,但隨後會將動態連結洩漏到後續的程式庫。(有關通常用於解決該問題的解決方案,請參閱 LINK_SEARCH_END_STATIC 目標屬性。)

當首次引入隱含連結目錄中程式庫的特殊情況時,隱含連結目錄的列表只是硬式編碼的(例如,/lib/usr/lib 和其他一些)。從那時起,CMake 已經學會偵測編譯器前端使用的隱含連結目錄。如有必要,可以教導 find_library() 命令使用此資訊來幫助找到正確架構的程式庫。

由於這些原因,CMake 3.3 及更高版本傾向於放棄特殊情況,即使程式庫位於隱含連結目錄中,也依完整路徑連結程式庫。策略 CMP0060 為現有專案提供相容性。

此策略的 OLD 行為是要求連結器搜尋已知完整路徑位於隱含連結目錄中的程式庫。此策略的 NEW 行為是即使程式庫位於隱含連結目錄中,也依完整路徑連結程式庫。

此策略在 CMake 3.3 版本中引入。在 CMake 4.0 版本中移除之前,可以透過 cmake_policy()cmake_minimum_required() 進行設定。如果未設定,CMake 預設不會發出警告,並使用 OLD 行為。

請參閱 CMAKE_POLICY_WARNING_CMP0060 變數的文件,以控制 CMake 4.0 之前版本中的警告。