Unable to load shared library : libxerces.so

Question

While running the application developed by other person, getting the following error

./appln: error while loading shared libraries: libxerces-c.so.28: cannot open shared object file: No such file or directory

And if I run ldd command:

# ldd appln
linux-gate.so.1 =>  (0x00e20000)
libdl.so.2 => /lib/libdl.so.2 (0x00a61000)
libxerces-c.so.28 => not found

I already have that libxerces-c.so.28 file in current folder. Please help me how to resolve that error

score 3 · Answer 1 · answered Sep 02 '14 at 07:40

3

You need to put libxerces-c.so somewhere in the library path. Probably current folder is not searched for libraries. Try putting it in /usr/local/lib

answered Sep 02 '14 at 07:40

Prof. Falken

24,226
19
100
173

Now I found that it is already there in /usr/local/lib, but still getting the error – Rajesh Kumar Sep 02 '14 at 07:42
or just do a `sudo make install` if you have build it (or `sudo ldconfig`) – sop Sep 02 '14 at 07:50

glezmen · Answer 2 · 2014-09-02T07:49:56.003

2

By default .so files are NOT being searched in the current folder (they should be in /usr/lib, etc). To add the current directory for .so lookup use:

LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH  ./appln

edited Sep 02 '14 at 07:49

answered Sep 02 '14 at 07:41

glezmen

554
2
5

$LD_LIBRARY is not there in my redhat linux – Rajesh Kumar Sep 02 '14 at 07:48

CB Bailey · Answer 3 · 2014-09-02T07:48:32.037

Evidently "the current folder" isn't in the run time search path used by your executable. I'm assuming that you are on linux (linux-gate.so.1).

You need to ensure that "the current" directory is under the search path. You can do this at link time by using the -rpath option to the linker (-R is also accepted) or -Wl,-rpath,<dir> if you are invoking the linker through the compiler front end. This embeds a search path to be used at run time into your program.

Consider how you want the program to be installed, though. There's no point in adding a path that is specific to your development environment. You might want to consider using $ORIGIN or a $ORIGIN relative path which tells the run time linker to look for shared objects in the location containing (or relative to) the executable. You should always avoid adding . to the run time search path; your program shouldn't behave differently depending on the current directory of the process which invokes it.

As a temporary measure you can set the environment variable LD_LIBRARY_PATH to override the embedded and system search paths but it is normally a bad idea to rely on LD_LIBRARY_PATH overrides for a final installation.

I am using redhat enterprise linux, what is the complete command that I need to execute — Rajesh Kumar, Sep 02 '14 at 07:47
@RajeshKumar: I don't know what the copmlete command that you need to execute because I don't know how you link your executable now. — CB Bailey, Sep 02 '14 at 07:49

score 2 · Answer 4 · edited May 23 '17 at 11:43

When adding new "local system" libraries (e.g. in /usr/local/lib/) you better add that directory (/usr/local/lib/) once in your /etc/ld.so.conf and you should run ldconfig to update the linker cache (every time you add something inside /usr/local/lib/)

See ldconfig(8), ld.so(8), ldd(1), dlopen(3)

If you want your own libraries, set LD_LIBRARY_PATH to a directory containing them (e.g. $HOME/lib/ and to standard directories, e.g.

 export LD_LIBRARY_PATH=$HOME/lib:/usr/lib:/usr/local/lib

in your ~/.bashrc (but I dislike that confusing practice, and prefer to manage my /usr/local/lib/).

You could also use some -Wl,-rpath argument but I really dislike that also.

Read also Program Library HowTo and Drepper's paper: How To Write Shared Libraries

This answer I like best. – Prof. Falken Sep 02 '14 at 09:15 — Prof. Falken, Sep 02 '14 at 09:15

Unable to load shared library : libxerces.so

4 Answers4