Я пытаюсь скомпилировать свою программу и возвращает эту ошибку:
usr/bin/ld: cannot find -l<nameOfTheLibrary>
в моем make файле я использую команду g++ и ссылку на мою библиотеку, которая является символической ссылкой на мою библиотеку, расположенную в другом каталоге.
Есть ли возможность добавить, чтобы заставить его работать?
Если имя вашей библиотеки указано libxyz.so, и оно находится по пути:
/home/user/myDir
затем, чтобы связать его с вашей программой:
g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
Чтобы выяснить, что ищет компоновщик, запустите его в подробном режиме.
Например, я столкнулся с этой проблемой при попытке скомпилировать MySQL с поддержкой ZLIB. Во время компиляции я получал такую ошибку:
/usr/bin/ld: cannot find -lzlib
Я сделал некоторые Googl'ing и продолжал сталкиваться с различными проблемами того же типа, где люди говорили бы, чтобы убедиться, что файл .so действительно существует, а если нет, то создайте символическую ссылку на файл с версией, например, zlib.so.1.2.8. Но, когда я проверил, zlib.so DID существует. Поэтому я подумал, что это не может быть проблемой.
Я столкнулся с другим сообщением в Internet, которое предложило запустить make с LD_DEBUG = all:
LD_DEBUG=all make
Хотя я получил TON отладочного вывода, на самом деле это не помогло. Это добавило больше путаницы, чем что-либо еще. Итак, я собирался сдаться.
Тогда у меня было прозрение. Я решил проверить текст справки для команды ld:
ld --help
Из этого я понял, как запустить ld в подробном режиме (представьте себе):
ld -lzlib --verbose
Это результат, который я получил:
==================================================
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.a failed
attempt to open /usr/local/lib64/libzlib.so failed
attempt to open /usr/local/lib64/libzlib.a failed
attempt to open /lib64/libzlib.so failed
attempt to open /lib64/libzlib.a failed
attempt to open /usr/lib64/libzlib.so failed
attempt to open /usr/lib64/libzlib.a failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.a failed
attempt to open /usr/local/lib/libzlib.so failed
attempt to open /usr/local/lib/libzlib.a failed
attempt to open /lib/libzlib.so failed
attempt to open /lib/libzlib.a failed
attempt to open /usr/lib/libzlib.so failed
attempt to open /usr/lib/libzlib.a failed
/usr/bin/ld.bfd.real: cannot find -lzlib
Ding, ding, ding...
Итак, чтобы окончательно исправить это, я мог бы скомпилировать MySQL с моей собственной версией ZLIB (а не в комплекте):
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so
Voila!
Кажется, что нет ответа, который бы затрагивал очень распространенную проблему начинающего с невозможностью установить требуемую библиотеку в первую очередь.
На платформах Debianish, если libfoo отсутствует, вы можете часто устанавливать его с чем-то вроде
apt-get install libfoo-dev
Версия пакета -dev требуется для работы по разработке, даже тривиальная разработка, такая как компиляция исходного кода для связи с библиотекой.
Название пакета иногда требует некоторых украшений (libfoo0-dev? foo-dev без префикса lib и т.д.), или вы можете просто использовать свой дистрибутив пакетный поиск, чтобы узнать, какие именно пакеты предоставляют конкретный файл.
(Если их больше одного, вам нужно будет выяснить, каковы их отличия. Выбор самого крутого или самого популярного - это общий ярлык, но не приемлемая процедура для любой серьезной работы по разработке.)
Для других архитектур (в частности, RPM) применяются аналогичные процедуры, хотя детали будут разными.
Во время компиляции с g++ через make определите LIBRARY_PATH, если может быть нецелесообразно изменять Makefile с опцией -L. Я поместил свою дополнительную библиотеку в /opt/lib, поэтому я сделал:
$ export LIBRARY_PATH=/opt/lib/
а затем выполнил make для успешной компиляции и компоновки.
Для запуска программы с общей библиотекой определите:
$ export LD_LIBRARY_PATH=/opt/lib/
перед выполнением программы.
Когда g++ говорит, что cannot find -l<nameOfTheLibrary>, это означает, что g++ искал файл lib{nameOfTheLibrary}.so, но не смог найти его в пути поиска в общей библиотеке, который по умолчанию указывает на /usr/lib и /usr/local/lib и где-то еще, может быть.
Чтобы решить эту проблему, вы должны либо предоставить библиотечный файл (lib{nameOfTheLibrary}.so) в этих путях поиска, либо использовать -l команды -l. -l{path} говорит g++ (на самом деле ld) найти библиотечные файлы в пути {path} в дополнение к путям по умолчанию.
Пример. Предположим, у вас есть библиотека по адресу /home/taylor/libswift.so, и вы хотите связать свое приложение с этой библиотекой. В этом случае вы должны предоставить g++ следующие опции:
g++ main.cpp -o main -L/home/taylor -lswift
Примечание 1: опция -l получает имя библиотеки без lib и .so в ее начале и конце.
Примечание 2: В некоторых случаях после имени файла библиотеки следует его версия, например libswift.so.1.2. В этих случаях g++ также не может найти файл библиотеки. Простой обходной путь для решения этой проблемы - создание символической ссылки на libswift.so.1.2 под названием libswift.so.
Когда вы связываете свое приложение с общей библиотекой, требуется, чтобы библиотека оставалась доступной при каждом запуске приложения. Во время выполнения ваше приложение (фактически динамический компоновщик) ищет свои библиотеки в LD_LIBRARY_PATH. Это переменная окружения, которая хранит список путей.
Пример: в нашем примере с libswift.so динамический компоновщик не может найти libswift.so в LD_LIBRARY_PATH (который указывает на пути поиска по умолчанию). Чтобы решить эту проблему, вы должны добавить эту переменную с путем libswift.so в.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor
Во-первых, вам нужно знать правило именования lxxx:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst
lc означает libc.so, lltdl означает libltdl.so, lXtst означает libXts.so.
Итак, это lib + lib-name + .so
Как только мы узнаем имя, мы можем использовать locate чтобы найти путь к этому файлу lxxx.so
$ locate libiconv.so
/home/user/anaconda3/lib/libiconv.so # <-- right here
/home/user/anaconda3/lib/libiconv.so.2
/home/user/anaconda3/lib/libiconv.so.2.5.1
/home/user/anaconda3/lib/preloadable_libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2.5.1
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/preloadable_libiconv.so
Если вы не можете найти его, вам нужно установить его с помощью yum (я использую CentOS). Обычно у вас есть этот файл, но он не ссылается на нужное место.
Ссылка на нужное место, обычно это /lib64 или /usr/lib64
$ sudo ln -s/home/user/anaconda3/lib/libiconv.so/usr/lib64/
Готово!
ссылка: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
При компиляции вашей программы вы должны указать путь к библиотеке; в g++ используйте параметр -L:
g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar
Эта ошибка может также возникнуть, если символическая ссылка относится к динамической библиотеке .so, но по причинам, связанным с устаревшими, -static появляется среди флагов ссылок. Если да, попробуйте удалить его.
Проверьте местоположение вашей библиотеки, например, lxxx.so:
locate lxxx.so
Если он не находится в папке /usr/lib, введите это:
sudo cp yourpath/lxxx.so /usr/lib
Готово.
Помимо ответов, которые уже были даны, может быть и так, что файл *.so существует, но не имеет правильного имени. Или это может быть случай, когда файл *.so существует, но он принадлежит другому пользователю /root.
Проблема 1: неправильное имя
Если вы связываете файл как -l<nameOfLibrary> тогда имя файла библиотеки ДОЛЖНО иметь форму lib<nameOfLibrary> Если у вас есть только файл <nameOfLibrary>.so, переименуйте его!
Проблема 2: Неправильный владелец
Чтобы убедиться, что это не проблема - сделайте
ls -l /path/to/.so/file
Если файл принадлежит пользователю root или другому пользователю, вам нужно сделать
sudo chown yourUserName:yourUserName /path/to/.so/file
В библиотеке, с которой я пытался ссылаться, оказалось нестандартное имя (т.е. не было префикс "lib" ), поэтому они рекомендовали использовать эту команду для ее компиляции -
gcc test.c -Iinclude lib/cspice.a -lm
Вот информация об Ubuntu моего ноутбука.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
Я использую locate, чтобы найти так файлы для boost_filesystem и boost_system
locate libboost_filesystem
locate libboost_system
Затем свяжите файлы так с /usr/lib и переименуйте в .so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so