CMake FIND_PACKAGE tiene éxito pero devuelve camino equivocado

Question

Estoy tratando de tener CMake 2.8.6 enlace para impulsar :: program_options utilizando el siguiente código en mi 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}) 

El comando find parece tener éxito, pero pasa el directorio incorrecto al enlazador. El paquete es realmente en:

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

pero CMakeFiles/segment.dir/link.txt enumera los siguientes:

/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 extra lib64 en el camino. Además, la bandera -l en frente de la ruta parece estar perdida.

Al ejecutar CMake se informa que se encuentra correctamente el paquete, y la variable {$Boost_LIBRARIES} parece una lista de las bibliotecas correctas:

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

El archivo generado CMakeCache.txt comienza 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 

Lo cual parece ser correcto. Pero cuando se ejecuta hacen utiliza la ruta en link.txt arriba y me sale el error:

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 

Lo que podría causar esta inyección adicional de un subdirectorio en el camino? ¿Qué podría causar que se genere link.txt de esta manera? ¿Y cómo lo soluciono (o lo soluciono)?

Answer 1

Este problema se produce cuando se utilizan algunas versiones anteriores de impulso con cmake-2.8.6-rc2 o posterior, donde se cambió el código hallazgo paquete de impulso.

El problema se puede solucionar especificando -DBoost_NO_BOOST_CMAKE=ON en la línea de comando cmake.

La confirmación real donde se presenta este problema es 7da796d1fdd7cca07df733d010cd343f6f8787a9, y puede ser viewed here.

Answer 2

Esto parece ser un problema con CMake 2.8.6 en CentOS. Al hacer lo mismo con 2.6.4 o 2.8.3, funciona correctamente. También con 2.8.7 en OS X también funciona correctamente.

Answer 3

También veo el problema de la versión cmake precompilado 2.8.8 usando CentOS 6.2 de 64 bits

Answer 4

El problema es con el archivo distribuido impulso-devel:/usr/lib64/impulso/Boost-RelWithDebInfo .cmake

El paquete cmake-2.6 no utiliza este archivo en absoluto, porque el archivo FindBoost.cmake devuelve (corrige) rutas completas para aumentar las bibliotecas. El archivo cmake28-2.8.8 FindBoost.cmake devuelve cadenas de biblioteca como "boost_date_time-mt-shared", que son objetivos definidos en /usr/lib64/boost/Boost-relwithdebinfo.cmake.

En la parte superior de /usr/lib64/boost/Boost-relwithdebinfo.cmake, una variable llamada _IMPORT_PREFIX se define desde la ubicación del archivo cmake sí mismo, y luego se usa de esta manera:

#---------------------------------------------------------------- 
# 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" 
) 

Esto establece _IMPORT_PREFIX en "/ usr/lib64", que se concatena con otra cadena que también tiene/lib64/en ella. Descubrí que si simplemente cambio el archivo para incluir una tercera llamada GET_FILENAME_COMPONENT, funciona bien. De este 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

me di cuenta este problema en la versión 2.8.11.2 cmake con 1.41.0-18.el6.x86_64 impulso

La respuesta aprobada no parece satisfactoria debido añadiendo esta definición al tiempo de ejecución cmake me sale:

CMake Advertencia: las variables especificado manualmente no fueron utilizados por el proyecto:

Boost_NO_BOOST_CMAKE 

me parece que no puede comentar o downvote debido a que no participen en stackoverflow suficiente. ¡Eso es un problema de huevo y pollo!

Tampoco puedo dar la espalda a la explicación de Kai Meyer. Sin embargo, creo que esto realmente explica el problema.

De lo que estoy reuniendo, parece que en resumen, FindBoost.cmake proporcionado por CMake parece de repente no encontrar Boost, por lo que el código de búsqueda ahora está buscando a través del script proporcionado boost para cmake, que a su vez tiene un error y parece no devolver el camino correcto.