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

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

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

/usr/bin/ld: cannot find -lzlib

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

я наткнулся на другой пост в Интернете, который предложил запустить 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++ via make определение LIBRARY_PATH если это не возможно, чтобы изменить Makefile с . Я поместил свою дополнительную библиотеку в /opt/lib так я и сделал:

$ export LIBRARY_PATH=/opt/lib/

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

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

$ export LD_LIBRARY_PATH=/opt/lib/

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

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

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

apt-get install libfoo-dev

на -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 {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

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

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

эта ошибка также может быть вызвана, если символическая ссылка относится к динамической библиотеке .Итак, но по причинам наследия -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.Итак:

locate lxxx.so

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

sudo cp yourpath/lxxx.so /usr/lib

сделано.

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

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

помимо уже данных ответов, может быть также Так, что *.таким образом, файл существует, но не назван должным образом. Или может быть так, что *.таким образом, файл существует, но он принадлежит другому пользователю / 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 было недостаточно, и мне пришлось перекомпилировать его на правильный путь.