views:

282

answers:

3

Hi,

I'm trying to compile a program running on an HP UX server on a Red Hat Linux.

It uses xerces-c library to parse xml files. Compilation is ok, but when i try to run it, I get the following message

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

I wrote a very simple program to try and understand whats going on:

#include <xercesc/util/PlatformUtils.hpp>
#include <xercesc/util/TransService.hpp>
#include <xercesc/parsers/SAXParser.hpp>
#include <xercesc/util/OutOfMemoryException.hpp>



int main(int argc, char* argv[])
{
        return 0;
}

And compiled it like this:

g++ test.cpp -L./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

Surprisingly the file is actually there:

lib]$ ls
libxerces-c.a   libxerces-c.so.28    libxerces-depdom.a   libxerces-depdom.so.28
libxerces-c.so  libxerces-c.so.28.0  libxerces-depdom.so  libxerces-depdom.so.28.0

Any thoughts ? I feel i'm missing something, but don't know what.

Thanks in advance.

+2  A: 

run ldd a.out and see if the linker can resolve the right .so file

export LD_LIBRARY_PATH to include the current folder (in the same manner as the PATH variable) and check ldd again

catwalk
thanks! ldd cant find libxerces-c.so.28 !!
Tom
A: 

the good way to do what you want is the following one:

g++ test.cpp -Xlinker -R ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

or

g++ test.cpp -Wl,-rpath ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include

Xlinker or Wl options allow you to use specific linking options, you do not need to modifiy LD_LIBRARY_PATH

Nadir SOUALEM
I dislike updating an executable's runtime search path for this, since it goes against the purpose of LD_LIBRARY_PATH. From the Wikipedia page for rpath linking: "The primary disadvantage of using RPATH is that it overrides the LD_LIBRARY_PATH settings which makes things like running a precompiled binary out of a user's home directory or some other non-default location difficult or impossible. Use of RPATH also makes it difficult, if not impossible, to upgrade libraries without forcing a reinstallation of all the software dependent on (even the older versions of) the libraries."
Emerick Rogul
so according to you , each time i install new library i must add it to the path ? So let's adding boost and all others shared damn libraries ...
Nadir SOUALEM
No. Every time you create a new library directory, you must add the new directory to LD_LIBRARY_PATH. But you shouldn't need to create new library directories all that often, since you can consolidate libraries in a single standard directory (/usr/local/lib or what have you).
Emerick Rogul
A: 

You need to tell the runtime c library where to find the various symbols that arent compiled statically in your code and arent in the usualy /lib and /usr/lib locations.

You do this by adding the path to your shared library to LD_LIBRARY_PATH. In this case, this will be what you have been putting for the -L argument to the compiler.

IanNorton