g++ shared object


$ls
libobject.so libobject.so.1 libobject.so.1.0 main.cpp main.o Makefile object.cpp object.h object.o

where:
libobject.so.1.0 - shared object
libobject.so.1 - symlink to so
libobject.so - symlink to so

$ g++ main.o -o exec -L. -lobject

$ ./exec
./exec: error while loading shared libraries: libobject.so.1: cannot open shared object file: No such file or directory

Why this does not work? When libobject.so.1.0 and symlinks to object are in /usr/lib it works fine.

ldd exec
linux-gate.so.1 => (0x003ad000)
libobject.so.1 => not found
WHY? why g++ does not find so in -L. directory?
Last edited on
I've read about LD_LIBRARY_PATH and so on.

LD_LIBRARY_PATH is broken and should not be used if at all possible. It's broken because it overrides the search paths for all binaries that you run using it, not just the one that you care about, and it doesn't add easily to other competing settings of LD_LIBRARY_PATH. It has a tendency to cause odd breakage,

What is the purpose of inserting -L parameter if I have to specify additional variable with directory for searching for libraries?

with .a libraries it works fine. Why it doesn't work with .so libraries?
-L tells the linker where to look for libraries at link time, not where to look for shared libs at run time.
There are a few different ways to specify the library path for runtime. There are a few reasons to avoid using LD_LIBRARY_PATH, although it is the easiest solution when the shared object is not in the environments default library path. It may also be helpful if you want to switch between different versions of the same library.

Some alternatives (acquired via Google) include:

1. Provide an installation facility that places the shared object in /usr/lib.
2. Use parameter(s) to embed a specific path to find the shared object during linking. Note that an installation facility could be provided that does the linking and sets the appropriate path for the user.
3. Instruct the user to add an additional library path in /etc/ld.so.conf and run ldconfig.
Last edited on
Topic archived. No new replies allowed.