Статическое связывание не удалось, хотя имя существует

Question

Я пытаюсь создать ссылку на статическую библиотеку libcovis.a. Все выглядит хорошо, но у меня все еще есть

неопределенная ссылка на `CoViG_PublicDemo :: MoInS :: reset () '

Я проверил, что имя существует в библиотеке

$ nm libcovis.a | сброс grep

...

_ZN16CoViG_PublicDemo5MoInS5resetEv

...

Я использую аргументы -L / path / to / libcovis.a -lcovis

Что я делаю не так?

Edit: Ошибка может быть что-то еще, если сделать

gcc main.cpp -I / usr / include / opencv -I / usr / include / cairo -I ../../ Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext - lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/litcilot_con_libcovis_conf lgl2ps

Работает!

Но когда я в KDevelop с помощью cmake, я больше не работаю. Я использую

CMAKE_EXE_LINKER_FLAGS: STRING = -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcauau / lcv -lcauc / -lxl-usl -lxl / usl -llvl / xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl-xl) - src / CoViS-0.0.0-1 / Source / libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps

CMAKE_CXX_FLAGS: STRING = -I / usr / local / src / CoViS-0.0.0-1 / Источник -I / usr / include / opencv -I / usr / include / cairo

Единственное различие, которое я вижу, состоит в том, что пути абсолютны, а не относительны, но если бы он не мог найти libs, он сказал бы это ...

Answer 1

Есть две разные проблемы, первая из которых самая простая, вы использовали неправильные параметры компилятора.Опция -L указывает компоновщику также искать в каталоге при поиске библиотеки.-L говорит ему, чтобы связать определенную библиотеку.Для связи вы должны использовать:

g ++ -o test test.o -L / path / to -lcovis

или

g ++ -o test test.o -l / path / to / libcovis.a

Для принудительного статического связывания, если одна и та же библиотека присутствует как динамическая библиотека в том же каталоге.

Вторая потенциальная проблема заключается в том, что порядок статических библиотек в командной строке компоновщика имеет значение, поэтому это также может быть проблемой, если есть зависимость от разных статических библиотек.

g ++ -o test tests.o -ldependent -lprovider

Компоновщик будет обрабатывать библиотеки в том порядке, в котором они находятся в командной строке, и из каждой статической библиотеки.он будет извлекать только те символы, которые требуются (с таким количеством информации, какое есть у компоновщика на тот момент).В приведенной выше командной строке компоновщик извлечет из dependent символов, которые ему необходимы для test.o, и это, в свою очередь, может добавить новые неопределенные символы в программу (зависимости dependent).Когда он обрабатывает provider, он заполняет эти символы.Если порядок был изменен в командной строке, символы, требуемые dependent, но не test.o, не будут добавлены в исполняемый файл, так как компоновщик не знает, что эти символы понадобятся при обработке provider.

Answer 2

Должны ли аргументы быть такими, как -L/path/to/ -lcovis?

Кроме того, объектные файлы должны быть помещены перед библиотеками, например

g++ obj1.o obj2.o -L/path/to/ -lcovis.

Answer 3

Если вы видите, что ссылка работает в одном контексте, но не в другом, я подозреваю, что проблема может быть вызвана порядком, в котором выполняется операция ссылки, так как компоновщик отбрасывает символы в библиотеке, если они не нужны вточка, на которую ссылается библиотекаВы сталкивались с подобными ситуациями в прошлом, и причина этой проблемы была обнаружена.