How to set the environmental variable LD_LIBRARY_PATH in linux
I have first executed the command: export LD_LIBRARY_PATH=/usr/local/lib Then I have opened .bash_profile file: vi ~/.bash_profile . In this file, I put:
LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH
Then if the terminal is closed and restarted, typing echo $LD_LIBRARY_PATH displays no result. How to set the path permanently?
Pointing it out the obvious here. If you just want to fix what you did, add a $ , e.g. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
this might be silly but did you $ source ~/.bash_profile ? I tend to forget that. And then like @neckTwi said run ldconfig
12 Answers 12
You should add more details about your distribution, for example under Ubuntu the right way to do this is to add a custom .conf file to /etc/ld.so.conf.d , for example
sudo gedit /etc/ld.so.conf.d/randomLibs.conf
inside the file you are supposed to write the complete path to the directory that contains all the libraries that you wish to add to the system, for example
remember to add only the path to the dir, not the full path for the file, all the libs inside that path will be automatically indexed.
Save and run sudo ldconfig to update the system with this libs.
Is this really the right way? Suppose you have multiple users building local libraries, and you’ve added both of them to /etc/ld.so.conf.d. Now user A can link to user B’s local libraries. Not good.
This was a lifesaver to resolve this problem: ‘ImportError: libpq.so.5: cannot open shared object file: No such file or directory error in SageMaker when trying to import psycopg2. Found the path using: $ find ~/ -name libpq.so.5 Then used @user1824407 suggestion: sudo vim /etc/ld.so.conf.d/pyscopg.conf followed by SageMaker location for libpg.so.5: /home/ec2-user/anaconda3/envs/JupyterSystemEnv/lib/ then ran sudo ldconfig. Magic.
This didn’t work for me, because afterwards, even after rebooting, echo $LD_LIBRARY_PATH is empty. (Ubuntu 20.04)
Keep the previous path, don’t overwrite it:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/your/custom/path/
You can add it to your ~/.bashrc :
echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/your/custom/path/' >> ~/.bashrc
Don’t ask me why, but this did not work, until I made this small change: mv ~/.bashrc ~/.bash_profile with otherwise the same code and same file privileges. It then worked. This is on Ubuntu 20.04.1 LTS. Without this file rename, LD_LIBRARY_PATH would still be empty on re-login. .bashrc was rwx for user, so it should execute fine. Executing it manually would also not set LD_LIBRARY_PATH (somewhat expected), and sourcing it ( . ./.bashrc ) did set it. Very odd, and I expect it’s Ubuntu 20.04.1 LTS specific.
CORRECTION: I should take my own advice and actually read the documentation. It says that this does not apply to LD_LIBRARY_PATH: Since Ubuntu 9.04 Jaunty Jackalope, LD_LIBRARY_PATH cannot be set in $HOME/.profile, /etc/profile, nor /etc/environment files. You must use /etc/ld.so.conf.d/.conf configuration files.* So user1824407’s answer is spot on.
Wow, I looked at that page several times and overlooked that. Thanks for spotting it and bringing it to our attention.
Ubuntu is a special case here. Ubuntu’s view is that all users want the same libraries and that there is only one place for each library (read discussion in Launchpad bug #366728). However, on multi-user research or development systems, you want each users to be able to have their own versions of libraries. Most Linux distributions allow this and have done so for many years.
Spent 4 hours trying to figure why I can set PATH and PKG_CONFIG_PATH, but not LD_LIBRARY_PATH. I can’t even.
@JoachimWagner Yes, this is correct, and why conda and/or bioconda or virtenv is now a preferred method on invoking a particular program with special environmental variables. By using encased environments, inadvertently setting the LD_LIBRARY path will not have systemic issues/problems.
Alternatively you can execute program with specified library dir:
/lib/ld-linux.so.2 --library-path PATH EXECUTABLE
Yeah I agree with spt025 — I never knew that trick was possible. I feel there is so much sort of hidden away stored in some archaic manpage at best . so StackOverflow is really helpful for THAT particular kind of information.
The file .bash_profile is only executed by login shells. You may need to put it in ~/.bashrc , or simply logout and login again.
For some reason no one has mentioned the fact that the bashrc needs to be re-sourced after editing. You can either log out and log back in (like mentioned above) but you can also use the commands: source ~/.bashrc or . ~/.bashrc .
Put export LD_LIBRARY_PATH=/usr/local/lib in ~/.bashrc [preferably towards end of script to avoid any overrides in between, Default ~/.bashrc comes with many if-else statements]
Post that whenever you open a new terminal/konsole, LD_LIBRARY_PATH will be reflected
- Go to the home folder and edit .profile
- Place the following line at the end export LD_LIBRARY_PATH=
- Save and Exit.
- Execute this command sudo ldconfig
You could try adding a custom script, say myenv_vars.sh in /etc/profile.d .
cd /etc/profile.d sudo touch myenv_vars.sh sudo gedit myenv_vars.sh
Add this to the empty file, and save it.
export LD_LIBRARY_PATH=/usr/local/lib
Logout and login, LD_LIBRARY_PATH will have been set permanently.
Awesome answer. Best choice for me to export a path every time during system initialisation and much safer than physically editing /etc/bashrc
I do the following in Mint 15 through 17, also works on ubuntu server 12.04 and above:
scroll to the bottom, and add:
All users have the environment variable added.
In Ubuntu 20.04 Linux this is just not obvious and straight forward as it should be.
I will attempt to make it simple for anyone who is pulling out their hair just like I was with my Ubuntu 20.04.3 Linux.
Start by identifying the path where your library files’ folder is located. In my case, the *.so files that I was working with were located in a folder called libs and this folder’s path in my Ubuntu box is /usr/lib
So now I want to add the path /usr/lib to LD_LIBRARY_PATH such that when I run echo $LD_LIBRARY_PATH in my Ubuntu terminal I will be able to see the path /usr/lib echoed as shown below;
joseph$ echo $LD_LIBRARY_PATH :/usr/lib
Here are the steps I used
- Open terminal in Ubuntu 20.04 Linux box
- Change path to /etc/ld.so.conf.d/ by running cd /etc/ld.so.conf.d/
- Create a file with a *.conf extension at the end with a text editor like e.g. vim or gedit in my case I created it as follows sudo gedit my_project_libs.conf
- Inside the .conf file that I created named my_project_libs.conf I added the path to my libs by adding this line export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
- Thereafter, I then run gedit ~/.bash_profile to open the ~/.bash_profile file so that I can add inside it this line export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib which includes the path to the folder with my libraries /usr/lib that I want included in LD_LIBRARY_PATH
- I also ran gedit ~/.bashrc to open the ~/.bashrc file so that I can add inside it this line export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib which includes the path to the folder with my libraries /usr/lib that I want included in LD_LIBRARY_PATH
- When you are done adding the line in step 5, save and close.
- In your terminal, type the following sudo ldconfig and press enter on your keyboard. Close all your open terminals that you were using then open a new terminal session and run echo $LD_LIBRARY_PATH If you see the path you added is echoed back, you did it right.
In my case, this is what I see :/usr/lib when I run echo $LD_LIBRARY_PATH in my newly opened Ubuntu terminal session
joseph$ echo $LD_LIBRARY_PATH :/usr/lib
That’s how I got it to work for me in my Ubuntu 20.04.3 Linux box.
Linux library loading path
В прошлый раз мы с Вами обнаружили, что запуск программ, скомпилированных вместе с динамическими библиотеками, вызывает ошибку:
dron:~# ./rezultdyn ./rezultdyn: error in loading shared libraries: libfsdyn.so: cannot open shared object file: No such file or directorydron:/#
Это сообщение выдает загрузчик динамических библиотек(динамический линковщик — dynamic linker), который в нашем случае не может обнаружить библиотеку libfsdyn.so. Для настройки динамического линковщика существует ряд программ.
Первая программа называется ldd. Она выдает на экран список динамических библиотек используемых в программе и их местоположение. В качестве параметра ей сообщается название обследуемой программы. Давайте попробуем использовать ее для нашей программы rezultdyn:
dron:~# ldd rezultdyn libfsdyn.so => not found libc.so.6 => /lib/libc.so.6 (0x40016000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) dron:~#
- libc.so.6 — стандартную библиотеку функций языка C++.
- ld-linux.so.2 — библиотеку динамической линковки программ ELF формата.
- libfsdyn.so — нашу динамическую библиотеку функций.
Нашу библиотеку она найти не может. И правильно! Динамический линковщик ищет библиотеки только в известных ему каталогах, а каталог нашей программы ему явно не известен.
Для того, чтобы добавить нашу директорию с библиотекой в список известных директорий надо подредактировать файл /etc/ld.so.conf. Например, у меня этот файл состоит из таких строк:
dron:~# cat /etc/ld.so.conf /usr/X11R6/lib /usr/i386-slackware-linux/lib /usr/i386-slackware-linux-gnulibc1/lib /usr/i386-slackware-linux-gnuaout/lib dron:~#
Во всех этих директории хранятся всеми используемые библиотеки. В этом списке нет лишь одной директории — /lib, которая сама по себе не нуждается в описании, так как она является главной. Получается, что наша библиотека станет «заметной», если поместить ее в один их этих каталогов, либо отдельно описать в отдельном каталоге. Давайте для теста опишем, добавим строку в конец файла ld.so.conf:
У меня этот файл валяется в домашнем каталога пользователя root, у Вас он может быть в другом месте. Теперь после этого динамический линковщик будет знать где можно найти наш файл, но после изменения конфигурационного файла ld.so.conf необходимо, чтобы система перечитала настройки заново. Это делает программа ldconfig. Пробуем запустить нашу программу:
dron:~# ldconfig dron:~# ./rezultdyn f1() = 25 f2() = 10 dron:~#
Как видите все заработало 🙂 Если теперь Вы удалите добавленную нами строку и снова запустите ldconfig, то данные о расположении нашей библиотеки исчезнут и будет появляться таже самая ошибка.
Но описанный метод влияет на всю систему в целом и требует доступа администратора системы, т.е. root. А если Вы простой пользователь без сверх возможностей ?!
Для такого случая есть другое безболезненное решение. Это использование специальной переменной среды LD_LIBRARY_PATH, в которой перечисляются все каталоги содержащие пользовательские динамические библиотеки. Для того, чтобы установить эту переменную в командной среде bash надо набрать всего несколько команд. Для начала посмотрим есть ли у нас такая переменная среды:
dron:~# echo $LD_LIBRARY_PATH
У меня в ответ выводится пустая строка, означающая, что такой переменной среды нет. Устанавливается она следующим образом:
dron:~# LD_LIBRARY_PATH=/root dron:~# export LD_LIBRARY_PATH
После этого программа rezultdyn будет прекрасно работать. В случае, если у Вас в системе эта переменная среды уже уставновлена, то, чтобы не испортить ее значение, надо новый каталог прибавить к старому значению. Делается это другой командой:
dron:~# LD_LIBRARY_PATH=/root:$ dron:~# export LD_LIBRARY_PATH
Если Вы обнулите эту переменную, то снова библиотека перестанет работать:
dron:~# LD_LIBRARY_PATH="" dron:~# export LD_LIBRARY_PATH dron:~# ./rezultdyn ./rezultdyn: error in loading shared libraries: libfsdyn.so: cannot open shared object file: No such file or directory dron:~#
Вы также параллельно можете зайти в систему под другим пользователем или даже тем же самым, но если Вы захотите просмотреть значение LD_LIBRARY_PATH, то увидите ее прежнее значение. Это означает, что два разных пользователя Linux не могут влиять на работу друг друга, а это и есть самое главное хорошее отличие систем Unix от большинства других систем.