c++ - studio - CMake FIND_PACKAGE tiene éxito pero devuelve una ruta incorrecta

visual studio installer

Question

Estoy tratando de tener el enlace CMake 2.8.6 para impulsar :: opciones del programa usando 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 vinculador. El paquete está realmente en:

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

pero CMakeFiles/segment.dir/link.txt enumera lo siguiente:

/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

Tenga en cuenta la lib64 adicional en la ruta. Además, la bandera -l en frente de la ruta parece estar perdida.

Al ejecutar CMake, informa que encuentra correctamente el paquete y la variable {$Boost_LIBRARIES} parece incluir 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 CMakeCache.txt generado 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 al ejecutar make usa la ruta en link.txt arriba y obtengo 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

¿Qué podría causar esta inyección extra 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

El problema es con el archivo distribuido boost-devel: /usr/lib64/boost/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 en sí, y luego se usa así:

#----------------------------------------------------------------
# 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. Al igual que:

#----------------------------------------------------------------
# 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 2

Este problema se produce cuando se utilizan versiones anteriores de boost con cmake-2.8.6-rc2 o posterior, donde se cambió el código de búsqueda del paquete boost.

El problema puede solucionarse 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 se puede ver aquí .

Answer 3

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 4

Me di cuenta de este problema en cmake versión 2.8.11.2 con boost-1.41.0-18.el6.x86_64

La respuesta aprobada no parece satisfactoria porque al agregar esto defino el tiempo de ejecución de cmake que obtengo:

CMake Warning: el proyecto no utilizó variables especificadas manualmente:

Boost_NO_BOOST_CMAKE

Parece que no puedo comentar o declinar debido a que no participo en lo 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 recopilando 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 por boost para cmake, que a su vez tiene un error y parece no devolver el camino correcto.

Answer 5

También veo el problema en la versión precompilada cmake 2.8.8 utilizando CentOS 64-bit 6.2