Як вказати місце розташування бібліотек у двійковій? (linux)


34

Для цього питання я буду використовувати конкретний приклад, але насправді це узагальнює майже будь-який бінарний на Linux, який, здається, не може знайти своїх залежних бібліотек. Отже, у мене є програма, яка не працюватиме через відсутність бібліотек:

./cart5: error while loading shared libraries: libcorona-1.0.2.so: cannot open shared object file: No such file or directory

ldd прояснює проблему:

linux-vdso.so.1 =>  (0x00007fff18b01000)
libcorona-1.0.2.so => not found
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/libstdc++.so.6 (0x00007f0975830000)
libm.so.6 => /lib/libm.so.6 (0x00007f09755af000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0975399000)
libc.so.6 => /lib/libc.so.6 (0x00007f0975040000)
libz.so.1 => /lib/libz.so.1 (0x00007f0974e2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0975b36000)

Однак корона встановлена:

oliver@human$ find / -name libcorona-1.0.2.so 2> /dev/null

/usr/local/lib64/libcorona-1.0.2.so
/home/oliver/installed/corona-1.0.2/src/.libs/libcorona-1.0.2.so

Як мені підказати бінарне, де шукати "відсутню" бібліотеку?

Відповіді:


43

Для одноразового використання встановіть змінну LD_LIBRARY_PATHв список відокремлених двокрапкою для пошуку. Це аналогічно PATHвиконуваним файлам, за винятком того, що стандартні системні каталоги додатково шукають ті, що вказані через середовище.

LD_LIBRARY_PATH=/usr/local/lib64 ./cart5

Якщо у вас є програма, яка зберігає бібліотеки в нестандартному місці і не може самостійно їх знайти, ви можете написати сценарій обгортки:

#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
else
  LD_LIBRARY_PATH=/usr/local/lib64
fi
export LD_LIBRARY_PATH
exec /path/to/cart5 "$@"

Список стандартних системних каталогів зберігається в /etc/ld.so.conf. Останні системи дозволяють цьому файлу включати інші файли; якщо ваш містить щось подібне include /etc/ld.so.conf.d/*.conf, створіть новий файл, який називається, /etc/ld.so.conf.d/mala.confщо містить каталоги, які ви хочете додати. Після зміни /etc/ld.so.confабо включеного файлу запустіть, /sbin/ldconfigщоб зміни набрали чинності (це оновлення кешу).

( LD_LIBRARY_PATHТакож відноситься і до багатьох інших Юнікси, включаючи FreeBSD, NetBSD, OpenBSD, Solaris і Tru64. HP-UX має SHLIB_PATHі Mac OS X має DYLD_LIBRARY_PATH. /etc/ld.so.confМає аналогів на більшості UNIXах , але розташування і синтаксис відрізняється більш широко.)


1
Фантастичний, дуже дякую Я не мав уявлення про /etc/ld.so.conf, і це буде мені дуже корисно в майбутньому.
Мала

15

Якщо ви хочете уникати LD_LIBRARY_PATH, ви також можете це зробити під час посилання:

gcc -o exename -L/path/to/dynamiclib/ -lnameofLib \
    -Wl,-R/path/to/dynamiclib/ sourceCode1.c ...

-Wl, ... використовується для передачі додаткових команд на лінкер, і в цьому випадку за допомогою -R ви повідомляєте лінкеру зберігати цей шлях як "шлях пошуку за замовчуванням" для .so.

Я зберігаю на своєму сайті записки багатьох маленьких порад, як ця:

https://www.thanassis.space/tricks.html


Але якщо сама відповідна бібліотека має спільні бібліотеки для пошуку, rpath, що зберігається у бінарному файлі, не застосовується рекурсивно до пошуку підтек. Я не знайшов іншого способу, крім встановлення LD_LIBRARY_PATH в оточенні, який потім застосовується до рекурсивних пошуку ...
Етан

@Ethan: Правда. Але також правдою є те, що звичайний сценарій, коли ви хочете "упакувати" спільні бібліотеки для деяких бінарних файлів, - це той, де ви розмістили їх усі разом; Наприклад /opt/mypackage/bin/someBinary, знадобляться бігуді, які ви зберігаєте /opt/mypackage/lib/. Практично всі власні SW, встановлені під / opt, дотримуються цього правила - це означає, що спосіб, показаний вище, охоплюватиме всі такі встановлення. Потім вони зазвичай додають також символьне посилання під / usr / bin, яке вказує на бінарний під / opt - знаючи, що "шлях пошуку за замовчуванням" знайде .sos у відповідній /opt/.../libпапці.
ttiodras

так, у моєму випадку я хотів протестувати пакет, пов'язуючи його каталог із збіркою, а не встановлюючи його ... (але пакет мав декілька внутрішніх. так що з деякими взаємозалежностями ... різноманітні обхідні шляхи, але просто дратують)
Ітан

0

Це вказує, що лібкорона не встановлена ​​в правильному шляху. Перемістіть каталог libcorona у правильний шлях, проблема буде вирішена ..


Чим це краще, ніж інші відповіді?
Тото

@За відміну від інших відповідей, ви в основному встановлюєте файли вручну ... Хоча це точно не означає, що ця відповідь є кращою, але це варіант, який слід враховувати (люди роблять це і в Windows, копіюючи бібліотеки в system32 / sysWOW64, коли їх програми не можуть їх знайти), це не рекомендується, оскільки це сильно не рекомендується.
Tcll
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.