usr / bin/ ld: не удается найти -l

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

например, я столкнулся с этой проблемой при попытке скомпилировать MySQL с поддержкой ZLIB. Я получал такую ошибку во время компиляции:

/usr/bin/ld: cannot find -lzlib

Я сделал некоторые Googl'ING и продолжал сталкиваться с различными проблемами того же рода, где люди сказали бы, чтобы убедиться, что файл .so действительно существует, а если это не так, то создайте символическую ссылку на версионный файл, например, с zlib.так.1.2.8. Но, когда я проверил, как zlib.так же существуют. Так что, подумал я, конечно, это не может быть проблемой.

я наткнулся на другой пост в Интернете, который предложил запустить make с LD_DEBUG=all:

LD_DEBUG=all make

хотя я получил тонну отладочного вывода, это было на самом деле не полезно. Это добавило больше путаницы, чем что-либо еще. Итак, я собирался сдаться.

тогда у меня было прозрение. Я думал на самом деле проверить текст справки для 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

Динь, Динь, Динь...

Итак, чтобы, наконец, исправить это, чтобы я мог скомпилировать MySQL с моей собственной версией ZLIB (а не в комплекте версии):

sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so

вуаля!

во время компиляции с g++ через make определение LIBRARY_PATH если это не возможно, чтобы изменить Makefile с . Я положил свою дополнительную библиотеку в /opt/lib так я и сделал:

$ export LIBRARY_PATH=/opt/lib/

а потом побежал make для успешной компиляции и связывания.

для запуска программы с общей библиотекой определите:

$ export LD_LIBRARY_PATH=/opt/lib/

перед выполнением программы.

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

на Дебианских платформах, если libfoo отсутствует, вы можете часто установить его с чем-то вроде

apt-get install libfoo-dev

The -dev версия пакета необходима для разработки, даже тривиальной разработки, такой как компиляция исходного кода для ссылки на библиотеку.

имя пакета иногда требуются некоторые украшения (libfoo0-dev? foo-dev без lib префикс? etc), или вы можете просто использовать ваш дистрибутив пакета поиск чтобы точно узнать, какие пакеты предоставляют конкретный файл.

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

для других архитектур (большинство примечательно, что RPM) применяются аналогичные процедуры, хотя детали будут отличаться.

Время Компиляции

когда G++ говорит cannot find -l<nameOfTheLibrary>, это означает, что G++ искал файл lib{nameOfTheLibrary}.so, но он не смог найти его в пути поиска общей библиотеки, который по умолчанию указывает на /usr/lib и /usr/local/lib и где-то еще может быть.

чтобы решить эту проблему, вы должны либо предоставить файл библиотеки (lib{nameOfTheLibrary}.so) в этих путях поиска или использовать -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.

---

Runtime

когда вы связываете свое приложение с общей библиотекой, требуется, чтобы библиотека оставалась доступной при каждом запуске приложения. Во время выполнения ваше приложение (фактически динамический компоновщик) ищет свои библиотеки в LD_LIBRARY_PATH. Это переменная среды, которая хранит список путей.

пример: в случае libswift.so пример, динамический компоновщик не может найти libswift.so на LD_LIBRARY_PATH (который указывает на пути поиска по умолчанию). Чтобы устранить проблему, вы должны добавить эту переменную с помощью пути libswift.so в.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor

при компиляции программы необходимо указать путь к библиотеке; в g++ используйте опцию-L:

g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar

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

во-первых, вам нужно знать правило именования 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 чтобы найти путь этого .

$ 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/

готово!

ref:https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html

проверьте расположение вашей библиотеки, например lxxx.so:

locate lxxx.so

если его нет в типа такого:

sudo cp yourpath/lxxx.so /usr/lib

сделано.

библиотека, на которую я пытался ссылаться, оказалась с нестандартным именем (т. е. не имела префикса 'lib'), поэтому они рекомендовали использовать такую команду для ее компиляции -

gcc test.c -Iinclude lib/cspice.a -lm

помимо уже данных ответов, также может быть так, что файл *.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

моя проблема заключалась в том, что я переименовал родительский каталог программы, которую я запускал (mpicc от MVAPICH), и это как-то испортило двоичный файл. Даже добавление LD_LIBRARY_PATH было недостаточно, и мне пришлось повторно скомпилировать его в правильный путь.