usr / bin / ld: не вдається знайти -l <nameOfTheLibrary>

Я намагаюся скласти свою програму, і вона повертає цю помилку:

usr/bin/ld: cannot find -l<nameOfTheLibrary>

у своєму makefile я використовую команду 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. так.1.2.8. Але, коли я перевірив, zlib.so DID існує. Отже, я подумав, це точно не може бути проблемою.

Я натрапив на ще одну посаду в Інтернеті, яка запропонувала запустити 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

Дін, дінь, дінь ...

Отже, щоб остаточно виправити це, щоб я міг компілювати MySQL із власною версією ZLIB (а не з пакетною версією):

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

Вуаля!

Здається, немає жодної відповіді, яка б вирішувала найпоширенішу проблему для початківців, коли не вдалося встановити потрібну бібліотеку.

На платформах Debianish, якщо libfooцього немає, ви можете часто встановлювати його з чимось подібним

apt-get install libfoo-dev

-devВерсія пакета потрібно для роботи в області розвитку, навіть тривіальні дослідно -конструкторські роботи , такі як компіляції вихідного коду для посилання на бібліотеку.

Ім'я пакета іноді потребує декору ( libfoo0-dev« foo-devбез libпрефікса» тощо), або ви можете просто скористатися пошуком пакета вашого дистрибутива, щоб точно з’ясувати, які пакети надають певний файл.

(Якщо їх більше, вам потрібно буде з’ясувати, в чому їх відмінності. Вибір найкрутішого чи найпопулярнішого - це звичайний ярлик, але не прийнятна процедура для будь-якої серйозної роботи з розробки.)

Для інших архітектур (особливо серед 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.

Час виконання

Коли ви зв’язуєте свій додаток із спільною бібліотекою, потрібно, щоб бібліотека залишалася доступною щоразу, коли ви запускаєте програму. Під час виконання ваш додаток (власне динамічний лінкер) шукає свої бібліотеки в LD_LIBRARY_PATH. Це змінна середовище, яка зберігає список шляхів.

Приклад: У випадку нашого libswift.soприкладу динамічний лінкер не може знайти libswift.soв LD_LIBRARY_PATH(який вказує на стандартні шляхи пошуку). Щоб вирішити проблему, слід додати цю змінну разом із шляхом libswift.so.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor

Під час компіляції з g++via makeвизначте, LIBRARY_PATHчи не є доречним змінити Makefile за допомогою -Lпараметра. Я поставив свою додаткову бібліотеку, /opt/libщоб я зробив:

$ export LIBRARY_PATH=/opt/lib/

а потім балотувався makeдля успішної компіляції та зв’язування.

Для запуску програми із спільною бібліотекою визначте:

$ export LD_LIBRARY_PATH=/opt/lib/

перед виконанням програми.

По-перше, вам потрібно знати правило іменування 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

Ця помилка також може виникнути, якщо символьне посилання на динамічну бібліотеку -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, щоб знайти .so файли для boost_filesystem та boost_system

locate libboost_filesystem
locate libboost_system

Потім прив’яжіть .so файли до / 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

Готово! R пакет velocyto.R був успішно встановлений!

Я зіткнувся з тим же повідомленням про помилку.

Я створив cmockaяк soі намагався пов’язати його зі своїм виконуваним файлом. Але ldзавжди скаржиться нижче:

/ usr / bin / ld: не вдається знайти -lcmocka

Виявляється, що після створення cmockaпобудовано 3 файли :

1. libcmocka.so
2. libcmocka.so.0
3. libcmocka.so.0.7.0

1 і 2 - це посилання символів, і лише 3 - це реальний файл.

Я лише скопіював 1 у свою папку бібліотеки, де ldне вдалося знайти 3.

Після того як я скопіював усі 3, ldпрацює.