Копирование и вставка файла .so не работает с компоновщиком

Я скомпилировал и построил остальную библиотеку casablanca C++ в своем домашнем каталоге, где мой абсолютный путь к необходимому файлу .so был /home/dev/casablanca/Release/build.release/Binaries/libcpprest.so. Что я хотел сделать, так это просто cp и вставить этот файл .so в /usr/lib/.. путь к поиску библиотеки по умолчанию ../, чтобы я мог легко связать его с помощью следующей команды:

g++ index.cpp -I/home/dev/casablanca/Release/include -lcpprest -std=c++11

который скомпилировался нормально, но когда я запустил ./a.out, я получил типичную ошибку времени выполнения:

couldn't load shared library: libcpprest.so

даже после добавления пути по умолчанию для libcpprest.so в LD_LIBRARY_PATH.

Однако все работало нормально, если я связал каталог, в котором изначально был создан двоичный файл:

// ./a.out runs just fine
g++ index.cpp -I/home/dev/casablanca/Release/include \
   -L/home/dev/casablanca/Release/build.release/Binaries -lcpprest -std=c++11

Я предполагаю, что причина, по которой я не могу просто переместить объект .so туда, куда я хочу его добавить, заключается в том, что компилятор каким-то образом сохраняет ссылки на него. Как я могу установить этот двоичный файл по другому пути?


c++ linux c++11 dynamic-library casablanca
person Dr.Knowitall    schedule 06.11.2014    source источник
comment
a.out, который работает просто отлично, не должен работать вообще, потому что -L не устанавливает никакого пути для поиска во время выполнения. Вы, наверное, не все рассказываете. Используйте ldd для своего исполняемого файла и библиотек и убедитесь, что среда одинакова во всех случаях. Кроме того, что это за usr/lib/..? Вы работаете как root и сбрасываете все на /usr?   -  person n. 1.8e9-where's-my-share m.    schedule 06.11.2014
comment
Я думаю, проблема может заключаться в том, что есть куча файлов .o, с которыми связывается .so. Если .so изменяет каталоги, это может привести к разрыву этих ссылок. Это мое предположение.   -  person Dr.Knowitall    schedule 06.11.2014
comment
Если .so изменяет каталоги, это может привести к разрыву этих ссылок. Только если вы проинструктируете компоновщика сделать это так, чего вы не сделали. Вы использовали ldd в своих исполняемых файлах и библиотеках? В выводе нет ничего подозрительного?   -  person n. 1.8e9-where's-my-share m.    schedule 06.11.2014
comment
эх, я сдаюсь, мне просто нужно было изменить файл cmake, чтобы через мою библиотеку в /usr/lib.   -  person Dr.Knowitall    schedule 06.11.2014

Ответы (2)


arrow_upward
1
arrow_downward

Я скомпилировал casablanca на моем linux debian ( https://git01.codeplex.com/casablanca ) с процедурой https://casablanca.codeplex.com/wikipage?title=Setup%20and%20Build%20on%20Linux&referringTitle=Documentation

после компиляции я получаю libcpprest.so с этим (objdump):

SONAME libcpprest.so.2.2

поэтому вы можете скопировать libcpprest.so.2.2 в /usr/lib/libcpprest.so.2.2

или используйте для этого инструмент ldconfig.

заглянув в Release/build.release/Binaries, вы найдете:

libcpprest.so -> libcpprest.so.2.2
libcpprest.so.2.2

тогда libcpprest.so — это просто ссылка, настоящая библиотека — libcpprest.so.2.2

person philippe lhardy    schedule 06.11.2014
comment
Я думаю, вам также нужно построить симлинк libcpprest.so -> libcpprest.so.2.2 - person Dr.Knowitall; 06.11.2014
comment
Я сделал это очень быстро сегодня утром и должен был уйти до завершения. я обновил свой ответ. Поскольку копирование относительной ссылки недостаточно, необходимо также скопировать исходную ссылку. - person philippe lhardy; 06.11.2014

arrow_upward
1
arrow_downward

Раздел, на который вы ссылаетесь, настраивается переключателем rpath:

g++ -Wl,-rpath,/path/to/lib ...

person erenon    schedule 06.11.2014