為什么cmake在64位系統上找到32位庫而不是64位庫？

Question

問題描述

我正在努力將幾個代碼庫從Red Hat 5移植到6，我遇到了一個cmake問題，我完全被這個問題困住了。

Cmake一直在/usr/lib下找到32位版本的庫而不是RHEL6系統上/usr/lib64下的64位版本，同時它正確地檢測RHEL5系統上的lib64版本。

最小的例子

例如，我有一個非常小的CMakeLists.txt文件：

cmake_minimum_required(VERSION 2.8)

find_library(XTEST X11)
message("Found X11 at ${XTEST}")

在RHEL6系統上，運行cmake導致：

$ cmake ..
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Found X11 at /usr/lib/libX11.so
-- Configuring done
-- Generating done
-- Build files have been written to: $HOME/software/64bit_problem/build

（這里的關鍵部分是Found X11 at /usr/lib/libX11.so的Found X11 at /usr/lib/libX11.so ）

但是，如果我在RHEL5系統上執行相同的操作，它會正確檢測/usr/lib64/ version :(請注意，我正在清除運行之間的CMakeCache.txt和其他臨時cmake文件。）

$ cmake ..
-- The C compiler identification is GNU 4.1.2
-- The CXX compiler identification is GNU 4.1.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Found X11 at /usr/lib64/libX11.so
-- Configuring done
-- Generating done
-- Build files have been written to: $HOME/software/64bit_problem/build

故障排除信息

兩個系統上都存在/usr/lib64版本的庫。 這是RHEL6系統的列表：

$ ls /usr/lib64/libX11.so*
/usr/lib64/libX11.so.6  /usr/lib64/libX11.so.6.3.0

在RHEL5系統上：

$ ls /usr/lib64/libX11.so*
/usr/lib64/libX11.so.6  /usr/lib64/libX11.so.6.3.0

只是為了確認/usr/lib確實是32位版本（同樣，它不是另一個位置的符號鏈接）：

$ file /usr/lib/libX11.so*
/usr/lib/libX11.so:       symbolic link to `libX11.so.6.3.0'
/usr/lib/libX11.so.6:     symbolic link to `libX11.so.6.3.0'
/usr/lib/libX11.so.6.3.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

$ file /usr/lib64/libX11.so*
/usr/lib64/libX11.so.6:     symbolic link to `libX11.so.6.3.0'
/usr/lib64/libX11.so.6.3.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

這可能是由於某個地方的環境設置，但我有點難過到哪里。 我沒有設置LD_LIBRARY_PATH ， LD_RUN_PATH或LDFLAGS 。 CFLAGS和CXXFLAGS 。 我的用戶環境應該是相同的，因為我的$ HOME是兩個機器上相同的NFS共享。

/usr/lib不在我的$PATH ，無論如何，將我的路徑限制為最小子集似乎沒有幫助：

$ export PATH=/bin:/usr/bin:$HOME/local/bin

$ cmake ..
<snip>
Found X11 at /usr/lib/libX11.so
-- Configuring done
<snip>

@SergyA有一個很好的建議，即使用ltrace檢查訪問哪些環境變量。 strace沒有從我能看到的任何診斷中找到任何診斷，但ltrace很好地顯示了環境變量訪問。 這是一個快速摘要：

$ ltrace -o ltrace_output cmake ..

$ grep getenv ltrace_output
getenv("PWD")                                                    = "$HOME/software/64bit_problem"
getenv("PATH")                                                   = "/bin:/usr/bin:$HOME/local/bin"
getenv("CMAKE_ROOT")                                             = NULL
getenv("MAKEFLAGS")                                              = NULL
getenv("VERBOSE")                                                = NULL
getenv("CFLAGS")                                                 = NULL
getenv("LDFLAGS")                                                = NULL
getenv("LDFLAGS")                                                = NULL
getenv("LDFLAGS")                                                = NULL
getenv("CXXFLAGS")                                               = NULL
getenv("LDFLAGS")                                                = NULL
getenv("LDFLAGS")                                                = NULL
getenv("LDFLAGS")                                                = NULL

cmake -specific Trobleshooting

兩台機器上的cmake版本是相同的（事實上，它是相同的可執行文件，原因我省略了簡潔）：

$ cmake --version
cmake version 2.8.11.2

$ which cmake
$HOME/local/bin/cmake

我已經嘗試顯式啟用FIND_LIBRARY_USE_LIB64_PATHS ，但這似乎沒有什么區別：

cmake_minimum_required(VERSION 2.8)

set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)

find_library(XTEST X11)
message("Found X11 at ${XTEST}")

正如@Ravi所提到的，這很可能是由於CMAKE_LIBRARY_PATH一些問題，但它沒有設置，並且將其更改為環境變量或cmake變量似乎沒有幫助。 但是，我完全承認我基本上不了解各種cmake配置變量，所以我很可能在這里遺漏了一些明顯的東西。

我最近意識到的一個關鍵因素是它不是所有庫...例如：

cmake_minimum_required(VERSION 2.8)

find_library(PNGTEST png)
message("Found libpng at ${PNGTEST}")

查找/usr/lib64/libpng.so而不是/usr/lib/libpng.so 。

這使我認為它無論如何都是特定於cmake的東西。

find_package而不是find_library

鑒於我上面提到的特定於庫的問題，我想嘗試找到整個X11包而不是單個庫（這正是我正在使用的代碼庫應該做的事情）。

但是，我得到了更令人困惑的結果......似乎是檢測到64位和32位庫的混合？ 例如：

cmake_minimum_required(VERSION 2.8)

FIND_PACKAGE(X11 REQUIRED)

message("X11_LIBRARIES: ${X11_LIBRARIES}")

我們會得到：

$ cmake ..
<snip>
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - not found
<snip>
-- Found X11: /usr/lib/libX11.so
X11_LIBRARIES: /usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib/libX11.so;/usr/lib/libXext.so
-- Configuring done
<snip>

但是，如果我們看一下X11_LIBRARIES中的這些特定庫，它們就是32位和64位版本的混合！

$ file /usr/lib64/libSM.so.6.0.1
/usr/lib64/libSM.so.6.0.1: ELF 64-bit LSB shared object, x86-64, <snip>

$ file /usr/lib64/libICE.so.6.3.0
/usr/lib64/libICE.so.6.3.0: ELF 64-bit LSB shared object, x86-64, <snip>

$ file /usr/lib/libX11.so.6.3.0
/usr/lib/libX11.so.6.3.0: ELF 32-bit LSB shared object, Intel 80386, <snip>

$ file /usr/lib/libXext.so.6.4.0
/usr/lib/libXext.so.6.4.0: ELF 32-bit LSB shared object, Intel 80386, <snip>

總之，我還應該嘗試什么？

我錯過了特定於cmake或特定於X11的配置選項嗎？

Answer 1

你可以嘗試：

list（INSERT 0 CMAKE_SYSTEM_LIBRARY_PATH / usr / lib64）

find_library使用的完整變量列表可在文檔中找到： https ：//cmake.org/cmake/help/v3.5/command/find_library.html

Answer 2

事實證明，根問題是版本后綴和RHEL6端特定的/usr/lib64/libX11.so缺少符號鏈接。

cmake專門針對libX11.so而不是libX11.so.6或其他一些特定於版本的變體。

在這種情況下，使符號鏈接不是一個選項，但我可以通過首先列出文件名來優先選擇特定版本：

cmake_minimum_required(VERSION 2.8)

find_library(XTEST NAMES libX11.so.6 X11)
message("Found X11 at ${XTEST}")

然而，毫無疑問，有很多更好的方法來處理這個問題，如果有人有任何更好的方法，我會非常有興趣聽到它們。