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.
Where do executables look for shared objects at runtime?
I understand how to define include shared objects at linking/compile time. However, I still wonder how do executables look for the shared object ( *.so libraries) at execution time. For instance, my app a.out calls functions defined in the lib.so library. After compiling, I move lib.so to a new directory in my $HOME . How can I tell a.out to go look for it there?
A quick solution is to use g++ -Wl,-R. this will force loader to look into the current folder for so libraries. Or -Wl,-R$HOME/path to specidy some other fixed folder.
4 Answers 4
The shared library HOWTO explains most of the mechanisms involved, and the dynamic loader manual goes into more detail. Each unix variant has its own way, but most use the same executable format (ELF) and have similar dynamic linkers¹ (derived from Solaris). Below I’ll summarize the common behavior with a focus on Linux; check your system’s manuals for the complete story.
(Terminology note: the part of the system that loads shared libraries is often called “dynamic linker”, but sometimes “dynamic loader” to be more precise. “Dynamic linker” can also mean the tool that generates instructions for the dynamic loader when compiling a program, or the combination of the compile-time tool and the run-time loader. In this answer, “linker” refers to the run-time part.)
In a nutshell, when it’s looking for a dynamic library ( .so file) the linker tries:
- directories listed in the LD_LIBRARY_PATH environment variable ( DYLD_LIBRARY_PATH on OSX);
- directories listed in the executable’s rpath;
- directories on the system search path, which (on Linux at least) consists of the entries in /etc/ld.so.conf plus /lib and /usr/lib .
The rpath is stored in the executable (it’s the DT_RPATH or DT_RUNPATH dynamic attribute). It can contain absolute paths or paths starting with $ORIGIN to indicate a path relative to the location of the executable (e.g. if the executable is in /opt/myapp/bin and its rpath is $ORIGIN/../lib:$ORIGIN/../plugins then the dynamic linker will look in /opt/myapp/lib and /opt/myapp/plugins ). The rpath is normally determined when the executable is compiled, with the -rpath option to ld , but you can change it afterwards with chrpath .
In the scenario you describe, if you’re the developer or packager of the application and intend for it to be installed in a …/bin , …/lib structure, then link with -rpath=’$ORIGIN/../lib’ . If you’re installing a pre-built binary on your system, either put the library in a directory on the search path ( /usr/local/lib if you’re the system administrator, otherwise a directory that you add to $LD_LIBRARY_PATH ), or try chrpath .
Where does Ubuntu look for shared libraries?
When I run a process that links to a shared library at runtime (linked when the process starts, not linked later with dlload() ), where does it look for that shared library ( .so ) file other than LD_LIBRARY_PATH ? Background: I have some C++ code that I wrote that uses a particular third-party library. I have installed the library and compiled my code on two different platforms, both Ubuntu but different versions, and different versions of gcc as well. The library was compiled and installed from source, and is located in /usr/local/lib on both platforms. When I compile my code, I link with the pkg-config —libs parameters for the third-party library and I’ve verified that pkg-config —libs returns the exact same thing on both platforms. My code compiles successfully on both platforms, and LD_LIBRARY_PATH is not defined (or defined as empty: «» ) on both platforms. However, when I run it on one platoform it works fine, and on the other I get this error:
error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory Funnily enough, the ones that doesn’t work is the newer version of Ubuntu and gcc. :/ So I’m trying to figure out how the working one is able to locate the library, so that I can make the broken one locate the library in the same way. (i.e., without setting LD_LIBRARY_PATH ) Update: Here’s my output from cat /etc/ld.so.conf.d/* . on the working (older) system:
/usr/lib/mesa /usr/lib32/mesa /usr/lib/alsa-lib # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/mesa