Как избежать «не могу открыть общий объектный файл» при использовании CMake?
ситуация
-
Мой проект использует CMake и без проблем компилируется на Ubuntu 16.04.
-
При запуске скомпилированного приложения я получаю сообщение не могу
открыть общий объектный файл. -
Все общие библиотеки объектов доступны в одном и том же нестандартном
папка (и они мне нужны там). - По некоторым причинам некоторые могут быть найдены, но другие не могут.
Что мне нужно
- Причина, по которой некоторые общие объекты могут быть найдены, а другие — нет. Проект довольно большой со многими файлами CMake. Я пытался найти различия между библиотеками, которые могут быть загружены, и теми, которые не могут, но безуспешно. Любая помощь, которая укажет мне правильное место, приветствуется.
- Решение внутри CMake, позволяющее находить все общие объекты.
LDD
LDD вывод показывает, что большинство общих объектов могут быть найдены. Вот некоторые примеры:
libboost_filesystem.so.1.55.0 => /path/to/libs/boost/lib/libboost_filesystem.so.1.55.0 (0x00007f2ed1fa0000)
libboost_filesystem.so.1.55.0 => /path/to/libs/boost/lib/libboost_filesystem.so.1.55.0 (0x00007f96af1f5000)
libboost_program_options.so.1.55.0 => /path/to/libs/boost/lib/libboost_program_options.so.1.55.0 (0x00007f96aef85000)
libboost_system.so.1.55.0 => /path/to/libs/boost/lib/libboost_system.so.1.55.0 (0x00007f96aed80000)
По некоторым причинам несколько других не могут быть найдены. Например:
libboost_iostreams.so.1.55.0 => not found
libboost_chrono.so.1.55.0 => not found
Существуют и другие не буст-либы, которые демонстрируют то же поведение, но для простоты я просто показываю примеры буста.
Обходы уже пробовали
Ниже приведены обходные пути, которые уже работают успешно. Но я действительно заинтересован в двух моментах в Что мне нужно раздел.
- Копирование в стандартные папки, такие как / USR / Lib и работает LDCONFIG
- Добавление пути к LD_LIBRARY_PATH
Решение
tldr; Убедитесь, что импортированная библиотека импортирована как SHARED или UNKNOWN, а не STATIC, и имеет свойство IMPORTED_SONAME.
Вы должны проверить, как импортируется библиотека, которую вы связываете.
Я проанализировал несколько экспортированных целей режима конфигурации для статических и динамических библиотек, и они немного отличаются по свойствам, которые они устанавливают для цели.
Например, для zlib, вот версия для статических библиотек:
add_library(ZLIB::zlibstatic STATIC IMPORTED)
set_target_properties(ZLIB::zlibstatic PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "C"IMPORTED_LOCATION_NOCONFIG "${_IMPORT_PREFIX}/lib/libz.a")
Однако для динамических библиотек это:
add_library(ZLIB::zlib SHARED IMPORTED)
set_target_properties(ZLIB::zlib PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${_IMPORT_PREFIX}/lib/libz.so.1.2.11"IMPORTED_SONAME_NOCONFIG "libz.so.1")
В сценарии режима модуля find_package вы можете подумать, что импортируете статическую библиотеку, хотя на самом деле найденная библиотека является .so, поэтому она может использовать неверные целевые свойства. В режиме конфигурации это маловероятно, потому что это намного более явно при определении цели. Хотя в режиме модуля (cmake / findXXX.cmake) вы часто определяете эти свойства в результате FIND_PACKAGE_HANDLE_STANDARD_ARGS Переменная _LIBRARIES, и трудно сказать, что вы собираетесь получить. Вы можете использовать libFoo.a в поиске, чтобы быть более явным или играть с CMAKE_FIND_LIBRARY_SUFFIXES.
Другие решения
Других решений пока нет …