Ld library path что это

Для чего используется LD_LIBRARY_PATH?

Прежде чем узнать LD_LIBRARY PATH, вы должны иметь представление о переменных среды. Но если вы не знаете, то не волнуйтесь, я объясню, что это такое. Переменные, значение которых определяется операционной системой или возможностями микрослужбы, называются переменными среды. Переменная среды – это динамически определяемое значение, которое может влиять на поведение запущенных компьютерных процессов. Процесс выполняется в компоненте среды процесса.

Сначала переменные среды были разработаны для UNIX, но теперь эти переменные есть и в Windows, и в Linux. Когда какой-либо процесс создается, он наследует копию среды выполнения своего родителя, за исключением явных изменений, сделанных родителем при создании дочернего процесса по умолчанию. Пара имя/значение составляет переменную среды, и любое их количество может быть сгенерировано и использовано в любое время. Обычно в именах переменных среды используются заглавные буквы. Это помогает отличать переменные среды от других типов имен в программном коде в целом. В операционной системе Unix переменные среды чувствительны к регистру, но не в DOS, OS/2 или Windows.

LD_LIBRARY также является переменной среды операционной системы UNIX/Linux; в этой статье мы подробно обсудим эту переменную среды.

Использование переменной LD_LIBRARY_PATH

В системе UNIX/Linux LD_LIBRARY_PATH указывает загрузчику динамической компоновки, небольшой программе, которая запускает все ваши приложения, чтобы определить, где искать динамические общие библиотеки, с которыми было связано приложение. Двоеточие (:) отделяет список каталогов, и этот список проверяется даже перед встроенными путями/путями поиска и обычными местоположениями, такими как (/lib, /usr/lib..).

Некоторые другие варианты использования LD_LIBRARY_PATH:

Проблема с LD_LIBRARY_PATH

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

Некоторые проблемы, возникающие при использовании LD_LIBRARY_PATH:

Безопасность: каталоги LD_LIBRARY_PATH проверяются в первую очередь, прежде чем их фактическое местоположение. Этот подход может быть использован злоумышленником, чтобы заставить ваше приложение запускать вредоносную версию общей библиотеки. Это одна из причин, по которой исполняемые файлы setuid/setgid игнорируют эту переменную.

Производительность: загрузчик ссылок должен просматривать все предоставленные каталоги, пока не найдет общие библиотеки (связанные с приложением). Следовательно, это приведет к открытию нескольких системных вызовов и их сбою с ENOENT «нет такого файла или каталога». Если указанный путь имеет много каталогов, это займет много времени, и вы можете проверить это во время запуска вашего приложения. В результате это приведет к замедлению работы всей системы.

Несогласованность. Наиболее распространенная проблема, связанная с использованием LD_LIBRARY_PATH, — несогласованность. LD_LIBRARY_PATH заставляет программу загружать разделяемую библиотеку, с которой она не была связана, что, безусловно, несовместимо с исходной версией. Это может быть очень очевидным, например, при сбое приложения, или может привести к неправильным результатам, если подобранная библиотека не совсем соответствует функциональности исходной версии. Это будет сложно отлаживать последнее, особенно.

Решение

Лучшее решение — чем меньше вы его используете, тем меньше проблем возникнет. На самом деле старайтесь избегать использования LD_LIBRARY_PATH:

Как избежать LD_LIBRARY_PATH:

Укажите правильное расположение разделяемой библиотеки. При компиляции приложения вам необходимо указать точное расположение разделяемых библиотек и указать путь в параметре компоновщика «-rpath», чтобы сообщить компоновщику о включении их в ваш путь запуска исполняемого файла или вы можете использовать переменную LD_RUN_PATH для указания нескольких путей

Инструмент для устранения проблемы: для исправления/изменения пути выполнения двоичного исполняемого файла доступны программы, такие как chrpath под Linux. Проблема в том, что исполняемое пространство, которое несет эту информацию (то есть строку пути), нельзя расширить, т. е. вы можете только переписать существующий путь.

Не помещайте LD_LIBRARY_PATH В ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ: Установив LD_LIBRARY_PATH в профиле пользователя, вы создадите себе проблемы, поэтому избегайте этого.

Не помещайте LD_LIBRARY_PATH В ПРОФИЛЬ СИСТЕМЫ. Некоторые независимые поставщики программного обеспечения предоставляют программное обеспечение, которое автоматически вставляет глобальные настройки LD LIBRARY PATH в системные профили во время установки или даже предлагает сделать это пользователю. Просто скажи нет! Попробуйте решить проблему другим способом, например, написав сценарий-оболочку, или попросите поставщика исправить ее.

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

Что такое LD_LIBRARY_PATH и как его использовать?

Я участвую в разработке Java-проекта, который использует некоторые компоненты С++, поэтому мне нужен Jacob.dll. (в Windows 7) Я продолжаю получать java.lang.UnsatisfiedLinkError: no JacobDB in java.library.path независимо от того, где я помещаю Jacob.dll. Я искал возможные решения, и тот, который я еще не пробовал, устанавливает переменную LD_LIBRARY_PATH, указывая на файл .dll. У меня мало опыта, и я не знаком с тем, что должно быть значением и использованием этой переменной — можете ли вы мне помочь?

karla 22 авг. 2011, в 16:02
Поделиться
Google: «java.library.path» . нажмите на любую ссылку, которая говорит об этом и DLL .
Nim 22 авг. 2011, в 13:18
и вот что я сделал ранее: inonit.com/cygwin/jni/helloWorld/load.html
Nim 22 авг. 2011, в 13:19

Если вы используете Windows и вам нужно загрузить эту dll, используйте системную переменную «PATH» или поместите dll в каталог Windows / System32. LD_LIBRARY_PATH не используется в Windows.

Paul Gregoire 27 авг. 2014, в 14:48
user202729 02 сен. 2018, в 07:08
Показать ещё 2 комментария
Поделиться:
environment-variables

4 ответа

Лучший ответ

Обычно вы должны установить java.library.path в командной строке JVM:

java -Djava.library.path=/path/to/my/dll -cp /my/classpath/goes/here MainClass

Henning Makholm 22 авг. 2011, в 13:57
Поделиться
ммм . но . что такое LD_LIBRARY_PATH?
JPCF 19 фев. 2017, в 15:37

LD_LIBRARY_PATH — это предопределенная переменная окружения в Linux/Unix, которая задает путь, на который должен ссылаться компоновщик, при связывании динамических библиотек/разделяемых библиотек.

LD_LIBRARY_PATH содержит список путей, разделенных двоеточиями, и компоновщик дает приоритет этим путям по стандартным путям библиотеки /lib и /usr/lib . Стандартные пути будут по-прежнему выполняться, но только после исчерпания списка путей в LD_LIBRARY_PATH .

Лучший способ использовать LD_LIBRARY_PATH — установить его в командной строке или script непосредственно перед выполнением программы. Таким образом, новый LD_LIBRARY_PATH изолирован от остальной части вашей системы.

$ export LD_LIBRARY_PATH="/list/of/library/paths:/another/path" $ ./program

Поскольку вы говорите о .dll , вы находитесь в системе Windows, а .dll должен быть помещен по пути, который компоновщик выполняет поиск по времени ссылки, в окнах этот путь задается переменной окружения PATH , So добавьте, что .dll в PATH , и он должен работать нормально.

Alok Save 22 авг. 2011, в 14:14
Поделиться

У меня есть проблема, PLZ, помогите мне тоже https://superuser.com/questions/1396481/java-application-not-picking-up-app-properties-on-widows-10

Arash 21 янв. 2019, в 19:03

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

Попробуйте добавить каталог, в котором ваша .dll находится в переменной PATH. Windows будет автоматически искать в списке каталогов эту переменную среды. LD_LIBRARY_PATH, вероятно, не решит проблему (если JVM не использует ее — я об этом не знаю).

Markus Pilman 22 авг. 2011, в 14:48
Поделиться

Спасибо, очевидно, это не сработает для меня. В противном случае, добавление элемента в переменную PATH было чем-то, что я сделал в первую очередь . пока безуспешно 🙂

karla 22 авг. 2011, в 13:24

Я не Java-разработчик, но не могли бы вы вывести переменную java.library.path (с помощью System.getProperty ())? Вы также можете попытаться установить эту переменную с флагом командной строки -D при запуске виртуальной машины — возможно, даже установка этого во время выполнения может сработать. Если вы работаете в Eclipse imho, есть способ установить что-то вроде «Места расположения собственной библиотеки» в настройке «Путь сборки» в свойствах проекта.

Markus Pilman 22 авг. 2011, в 13:29

Не линукс !! Все Unixes используют эту переменную окружения! Также это не для ссылки, но для загрузки! Статические связанные библиотеки обычно передаются компоновщику в командной строке, динамически загружаемые библиотеки ищутся через LD_LIBRARY_PATH. Смотрите, например, linuxmafia.com/faq/Admin/ld-lib-path.html

Angel O’Sphere 22 авг. 2011, в 13:37

@Angel O’Sphere: 1-й: динамический компоновщик будет использовать это для загрузки. 2-е: Mac OS X использует DYLD_LIBRARY_PATH. Конечно: LD_LIBRARY_PATH не специфичен для Linux, но я думаю, что в контексте вопроса это — pettifoggery. Ну и кстати: я писал о загрузке — так где вы видите что-нибудь о связывании и LD_LIBRARY_PATH в моем комментарии?

Markus Pilman 22 авг. 2011, в 13:44

У меня проблема, пожалуйста, помогите мне https://superuser.com/questions/1396481/java-application-not-picking-up-app-properties-on-widows-10

Arash 21 янв. 2019, в 19:03
Показать ещё 3 комментария

Ну, сообщение об ошибке сообщает вам, что делать: добавьте путь, где Jacob.dll находится в java.library.path. Вы можете сделать это в командной строке следующим образом:

java -Djava.library.path="dlls" .

(предполагая, что Jacob.dll находится в папке «dlls» )

daniel kullmann 22 авг. 2011, в 14:47
Поделиться
После запуска JVM вы не можете установить java.library.path таким образом.
Lorand Bendig 08 март 2013, в 21:08

Ещё вопросы

0 показывая загрузочный образ php
1 Что означает судебный процесс Oracle против Google для разработчиков Android?
0 скольжение переполняется, пока слайд и слайд используются постоянно
1 Автоматический слайдер JS?
0 jquery Map () не работает над списком HTML
0 как прекратить действия с помощью JavaScript
0 C ++ Escape Символьные и ссылочные переменные Выходные данные Путаница
0 Необработанное исключение, не похоже, что что-то не так
0 PHP неправильно передает переменную
0 Оценка рисков allow_url_include или альтернатив
0 Кэширование интерфейса Webapp и восстановление его с помощью html5 localstorage
0 как создать представление, когда несколько групп, использующих Mysql
1 Утечка памяти при попытке сохранить ссылку на фрагментное представление за пределы onDestoryView ()
1 создание символической ссылки для strings.xml в папке значений
0 CSV поле соответствия в где
0 Два деления в одной строке
1 Автоматическая установка плагинов в Android Studio
1 Периодическая интерполяция со scipy sqlrep
0 Удаление различий между объектами и массивами из разных массивов
0 Начальная точка Директивы угловой группировки
0 динамическая настройка высоты div, чтобы нижний колонтитул был внизу, если содержимое не заполняет окно
0 Как динамически сгенерировать mysql ON DUPLICATE UPDATE в python
0 Boost Unit Test: поймать неудачный тест
0 $ index перезапустить каждую строку в ng-repeat
1 JavaScript проблема об «этом»
0 отладка __do_global_dtors_aux, чтобы найти расположение кода
1 элементы графика времени vis.js в неправильном положении
1 Storage Access Framework: сохранить права доступа к файлам после отзыва дерева разрешений
1 умножить строковый элемент на элемент int из двух массивов Java
0 не работает
1 Android, как я могу выбрать изображение с камеры или галереи одновременно с одним намерением
1 Maven: неправильная версия Hibernate?
1 Ошибки Entity Framework Validation неправильно обрабатываются клиентом breeze.sharp
0 использование CSS-перехода при опрокидывании другого элемента
1 Как сохранить несколько URL-адресов в виде файла на StartURL в Scrapy — Python?
1 Заполнение объекта при инициализации с использованием его конструктора и объекта, возвращенного из сериализованного потока
0 Перерыв на слово в iOS7
1 Jsoup удалить конкретный идентификатор TR
1 переадресация sshagent в jenkins не работает
1 Как запустить новый файл Node.js после того, как уже был запущен какой-либо другой файл Node.js. на компьютере с Windows 10?
1 FileLoadException не обработан
0 как уменьшить строки JavaScript вместо повторения
0 Идентификатор возвращает 0 для API отдыха с Go
0 AngularJS $ http запрос на исправление не отправляет данные
0 Открытие локального файла XML в Google Chrome
0 пространство имен против соглашения об именах
1 Украшение именованных компонентов в виндзоре
1 Понимание «побочных эффектов» в Javascript с учетом функций первого класса
0 Проблема с перенаправлением страницы контактов
0 SQL: как выбрать одну строку в день

LD_LIBRARY_PATH – or: How to get yourself into trouble!

This little note is about one of the most “misused” environment variables on Unix systems: LD_LIBRARY_PATH . If used right, it can be very useful, but very often – not to say, most of the time – people apply it in the wrong way, and that is were they are calling for trouble.

So, what does it do?

LD_LIBRARY_PATH tells the dynamic link loader (ld. so – this little program that starts all your applications) where to search for the dynamic shared libraries an application was linked against. Multiple directories can be listed, separated by a colon (:), and this list is then searched before the compiled-in search path(s), and the standard locations (typically /lib, /usr/lib, …).

This can be used for

testing new versions of a shared library against an already compiled application
re-locating shared libraries, e.g. to preserve old versions
creating a self-contained, relocatable(!) environment for larger applications, such that they do not depend on (changing) system libraries – many software vendors use that approach.

Sounds very useful, where is the problem?

Yes, it is useful – if you apply it in the way it was invented for, like the three cases above. However, very often it is used as a crutch to fix a problem that could have been avoided by other means (see below). It is even getting worse, if this crutch is applied globally into an user’s (or the system’s!) environment: applications compiled with those settings get dependent on this crutch – and if it is eventually taken away, they start to stumble (i.e. fail to run).

There are other implications as well:

Security: Remember that the directories specified in LD_LIBRARY_PATH get searched before(!) the standard locations? In that way, a nasty person could get your application to load a version of a shared library that contains malicious code! That’s one reason why setuid/setgid executables do neglect that variable!
Performance: The link loader has to search all the directories specified, until it finds the directory where the shared library resides – for ALL shared libraries the application is linked against! This means a lot of system calls to open(), that will fail with “ENOENT (No such file or directory)”! If the path contains many directories, the number of failed calls will increase linearly, and you can tell that from the start-up time of the application. If some (or all) of the directories are in an NFS environment, the start-up time of your applications can really get long – and it can slow down the whole system!
Inconsistency: This is the most common problem. LD_LIBRARY_PATH forces an application to load a shared library it wasn’t linked against, and that is quite likely not compatible with the original version. This can either be very obvious, i.e. the application crashes, or it can lead to wrong results, if the picked up library not quite does what the original version would have done. Especially the latter is sometimes hard to debug.

How can I check which dynamic libraries are loaded?

There is the ldd command, that shows you which libraries are needed by a dynamically linked executable, e.g.

$ ldd /usr/bin/file linux-vdso.so.1 => (0x00007fff9646c000) libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00000030f9a00000) libz.so.1 => /lib64/libz.so.1 (0x00000030f8e00000) libc.so.6 => /lib64/libc.so.6 (0x00000030f8200000) /lib64/ld-linux-x86-64.so.2 (0x00000030f7a00000)

This is a ‘static’ view, since ldd doesn’t resolve dependencies and libraries that will get loaded at runtime, e.g. by a library that depends on others. To get an overview of libraries loaded at runtime, you can use the pldd command:

$ ldd /bin/bash linux-vdso.so.1 => (0x00007ffff63ff000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003108a00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000030f8600000) libc.so.6 => /lib64/libc.so.6 (0x00000030f8200000) /lib64/ld-linux-x86-64.so.2 (0x00000030f7a00000) $ pldd 24362 24362: -bash /lib64/ld-2.12.so /lib64/libc-2.12.so /lib64/libdl-2.12.so /lib64/libtinfo.so.5.7 /usr/lib64/gconv/ISO8859-1.so /lib64/libnss_files-2.12.so

As you can see, there are two more .so-files loaded at runtime, that weren’t on the ‘static’ list.

Note: pldd is originally a Solaris command, that usually is not available on Linux. However, there is a Perl-script available (and installed on our machines) that extracts this information from the /proc//maps file.

How to avoid those problems with LD_LIBRARY_PATH?

A very simplistic answer would be: “just don’t use LD_LIBRARY_PATH!” The more realistic answer is, “the less you use it, the better off you will be”.

Below comes a list of ways how to avoid LD_LIBRARY_PATH, inspired by reference [1] below. The best solution is on the top, going down to the last resort.

cc -o myprog obj1.o . objn.o -Wl,-rpath=/path/to/lib \ -L/path/to/lib -lmylib

The linker also reads the LD_RUN_PATH environment variable, if set, and thus you can specify more than one path in an easy way, without having to use the above linker option:

export LD_RUN_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3 cc -o myprog obj1.o . objn.o -L/path/to/lib1 -lmylib1 \ -L/path/to/lib2 -lmylib2 .

#!/bin/sh LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3 export LD_LIBRARY_PATH exec /path/to/bin/myprog $@

$ env LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3 ./myprog

This sets LD_LIBRARY_PATH for this command only. Do NOT do:

$ export LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3 $ ./myprog

Unfortunately, some ISVs ship software, that puts global LD_LIBRARY_PATH settings into the system profiles during the installation, or they ask the user to add those settings to their profiles. Just say no! Try if you can solve the problem by other means, e.g. by creating a wrapper script, or tell the vendor to fix this problem.

More references on the net:

Сохранение переменной LD_LIBRARY_PATH в Linux

@Mike релог — это exit, закрытие терминала и открытие его снова, новое подключение по ssh. Пробовал прописывать и в $HOME/.bashrc и в $HOME/.bash_ profile — безрезультатно, переменная пустая при следующем входе в истему.

13 мар 2019 в 6:42

А у пользователя какой shell стоит ? Может не bash и тогда у него свои файлы старта сеанса. Для bash .bashrc или .bash_profile должны помогать. Можете в них для проверки какой нибудь echo написать, убедится что при входе пользователя строка эта будет выведена на экран (см. на пользователя в /etc/passwd). И вы же под $HOME точно домашний каталог нужного пользователя подразумевали (там же в passwd проверьте что это он)

13 мар 2019 в 6:53

@Mike ага, вот где собака зарыта. у рута bin/bash, а у этого пользователя оказалось /bin/sh. Огромное спасибо! Тогда вытекающий вопрос: где лежат аналогичные файлы для /bin/sh или как сменить пользователю оболочку и какие последствия это может повлечь?

13 мар 2019 в 7:00

/bin/sh скорее всего ссылка на какой нибудь другой shell (посмотрите в /bin не является ли он ссылкой). просто sh обычно не используется. но если это он, то $HOME/.profile (кстати он для многих оболочек может быть рабочим). Менять шелл можно с помощью chsh linux.die.net/man/1/chsh или просто поправьте в /etc/passwd. Последствий обычно никаких. Если сложных не bash скриптов тот пользовтель не писал (что очень вряд ли, учитывая что вы ранее не знали какой у него шелл 🙂 )

13 мар 2019 в 7:03

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