CMake FIND_PACKAGE riesce ma restituisce strada sbagliata

Question

Sto cercando di avere CMake 2.8.6 link per boost :: program_options utilizzando il seguente codice nel mio CMakeLists.txt

FIND_PACKAGE(Boost COMPONENTS program_options REQUIRED) 
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIR}) 

ADD_EXECUTABLE (segment segment.cpp) 
TARGET_LINK_LIBRARIES (segment ${Boost_LIBRARIES}) 

Il comando find sembra riuscire ma passa la directory sbagliata per il linker. Il pacchetto è in realtà:

`/usr/lib64/libboost_program_options-mt.so.5` 

ma CMakeFiles/segment.dir/link.txt elenca i seguenti:

/cm/shared/apps/gcc/4.4.6/bin/c++  CMakeFiles/segment.dir/segment.cpp.o -o segment -rdynamic /usr/lib64/lib64/libboost_program_options-mt.so.5 -lpthread -lrt -Wl,-rpath,/usr/lib64/lib64 

nota l'extra lib64 nel percorso. Inoltre, la flag -l di fronte al percorso sembra mancare.

Quando si esegue CMake esso segnala che trova correttamente il pacchetto, e la variabile {$Boost_LIBRARIES} sembra di elencare le librerie corrette:

Boost found. 
Found Boost components: 
    program_options 
${Boost_LIBRARIES} - optimized;boost_program_options-mt-shared;debug;boost_program_options-mt-shared-debug 

Il file generato CMakeCache.txt inizia con:

//The directory containing a CMake configuration file for Boost. 
Boost_DIR:PATH=/usr/lib64/boost 

//Boost include directory 
Boost_INCLUDE_DIR:FILEPATH=/usr/include 

Che sembra essere corretto Ma quando si esegue lo rendono utilizza il percorso in link.txt sopra e ottengo l'errore:

make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_program_options-mt.so.5', needed by `segment'. Stop. 
make[1]: *** [CMakeFiles/segment.dir/all] Error 2 
make: *** [all] Error 2 

cosa potrebbe causare questa iniezione in più di una sottocartella nel percorso? Cosa potrebbe causare che link.txt sia generato in questo modo? E come posso risolvere il problema (o aggirarlo)?

Answer 1

Questo problema si verifica quando si utilizzano alcune vecchie versioni di spinta con cmake-2.8.6-rc2 o poi, in cui è stato cambiato il codice ritrovamento pacchetto di spinta.

Il problema può essere risolto specificando -DBoost_NO_BOOST_CMAKE=ON sulla riga di comando cmake.

Il commit effettivo in cui viene introdotto questo problema è 7da796d1fdd7cca07df733d010cd343f6f8787a9 e può essere viewed here.

Answer 2

Questo sembra essere un problema con CMake 2.8.6 su CentOS. Quando si fa lo stesso con 2.6.4 o 2.8.3 funziona correttamente. Anche con 2.8.7 su OS X funziona anche correttamente.

Answer 3

vedo anche il problema sul pre-compilato versione 2.8.8 CMake usando CentOS 64 bit 6.2

Answer 4

Il problema è con il file distribuito spinta-devel:/usr/lib64/boost/Boost-relwithdebinfo .cmake

Il pacchetto cmake-2.6 non utilizza affatto questo file, perché il file FindBoost.cmake restituisce (corretto) percorsi completi per incrementare le librerie. Il file cmake28-2.8.8 FindBoost.cmake restituisce stringhe di libreria come "boost_date_time-mt-shared", che sono obiettivi definiti in /usr/lib64/boost/Boost-relwithdebinfo.cmake.

Al vertice della /usr/lib64/boost/Boost-relwithdebinfo.cmake, una variabile denominata _IMPORT_PREFIX è definito dalla posizione del file CMake in sé, e quindi utilizzato in questo modo:

#---------------------------------------------------------------- 
# Generated CMake target import file for configuration "RelWithDebInfo". 
#---------------------------------------------------------------- 

# Commands may need to know the format version. 
SET(CMAKE_IMPORT_FILE_VERSION 1) 

# Compute the installation prefix relative to this file. 
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) 
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) 

# Import target "boost_date_time-static" for configuration "RelWithDebInfo" 
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO) 
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES 
    IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a" 
) 

Ciò imposta _IMPORT_PREFIX su "/ usr/lib64", che è concatenato con un'altra stringa che contiene/lib64/anche in esso. Ho scoperto che se ho semplicemente modificato il file per includere una terza chiamata GET_FILENAME_COMPONENT, funziona correttamente. In questo modo:

#---------------------------------------------------------------- 
# Generated CMake target import file for configuration "RelWithDebInfo". 
#---------------------------------------------------------------- 

# Commands may need to know the format version. 
SET(CMAKE_IMPORT_FILE_VERSION 1) 

# Compute the installation prefix relative to this file. 
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) 
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) 
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) 

# Import target "boost_date_time-static" for configuration "RelWithDebInfo" 
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO) 
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES 
    IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a" 
) 

Answer 5

ho notato questo problema in cmake versione 2.8.11.2 con boost-1.41.0-18.el6.x86_64

La risposta approvato non sembra soddisfacente, perché aggiungendo questa definire al runtime cmake ottengo:

CMake Attenzione: variabili manualmente specificati non sono stati utilizzati dal progetto:

Boost_NO_BOOST_CMAKE 

io non riesco a commentare o downvote a causa di non partecipare a StackOverflow abbastanza. Questo è un problema di pollo e uova!

Anche io non riesco a modificare la spiegazione di Kai Meyer. Tuttavia, penso che questo spieghi davvero il problema.

Da quello che sto raccogliendo sembra che, in breve, FindBoost.cmake fornito da CMake sembra improvvisamente non riuscire a trovare Boost, quindi il codice di ricerca ora sta cercando tramite lo script fornito da boost per cmake, che a sua volta ha un bug e sembra non restituire il percorso corretto.