Linux linking a shared object

Question

I am linking an so, that depends on libmxml.so. However I have no rights install libmxml.so.

So thats what I am doing

gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -L ../../../../system/addonlibs/ -lmxml -lpthread

ldd shows me

ldd ServiceProvider.so 
    libmxml.so.1 => not found
    libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
    libc.so.6 => /lib/libc.so.6 (0x40046000)

the second try was

gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o ../../../../system/addonlibs/libmxml.so -lpthread

and still ldd shows me

ldd ServiceProvider.so 
    libmxml.so.1 => not found
    libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
    libc.so.6 => /lib/libc.so.6 (0x40046000)

Consequently, ldd does not find the library, since I only have "libmxml.so", but no "libmxml.so.1". How do I get rid of this ".1" suffix? Why is it comming?

Do you actually have a shared library for libmxml, or is it a static library? — Mats Petersson, Jun 14 '13 at 07:44
it is a shared library, I do have the libmxml.so from the build — Stasik, Jun 14 '13 at 07:45
Do you actually mean LIBRARY_PATH? Since I have compile-problems. — Stasik, Jun 14 '13 at 07:48
It's not a compile time problem. `ldd` shows you what the loader thinks should be loaded - `LD_LIBRARY_PATH` is the one you want. Try it... — Mats Petersson, Jun 14 '13 at 07:50
it does not help, since it searches for "libmxml.so.1", but i have only "libmxml.so" in the LD_LIBRARY_PATH. I am wondering, where this ".1" is coming from — Stasik, Jun 14 '13 at 07:51
In this case, just rename `libmxml.so` to `libmxml.so.1`, or make a symlink. Take a look at `/usr/lib`. You will see that it is a common practice. — Matthieu Rouget, Jun 14 '13 at 07:56
Yes, thats how i solved it, but I'd know where .1 is coming from, is it kinda compiled into the .so file as 'soname'? — Stasik, Jun 14 '13 at 07:58

Matthieu Rouget · Accepted Answer · 2013-06-14T08:28:49.100

0

When you link with a dynamic library, you should not do :

gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o ../../../../system/addonlibs/libmxml.so -lpthread

Instead, make sure that /yourpath/system/addonlibs (you should use the full path instead of a relative one) is in you LIBRARY_PATH. Then change you link command.

export LIBRARY_PATH=/yourpath/system/addonlibs:$LIBRARY_PATH
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -lmxml -lpthread

You can also write that:

gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -L/yourpath/system/addonlibs -lmxml -lpthread

However, to run your program, you will need to have your library path in LD_LIBRARY_PATH.

If you have issues with .soand .so.1 stuff, then rename your .so to .so.1 and make a symlink from .so.1 to .so.

Edit:

If you do objdump -p libmxml.so | grep SONAME you will probably get libmxml.so.1. It is where you get the libmxml.so.1 identifier.

edited Jun 14 '13 at 08:28

answered Jun 14 '13 at 07:59

Matthieu Rouget

3,009
16
22

Or individually with `-l` option like so : `-l/yourpath/system/addonlibs/libmxml.so.1` – Gauthier Boaglio Jun 14 '13 at 08:09
are you sure about export LD_LIBRARY_PATH? I'd guess it is just LIBRARY_PATH. You did not answer the question about ".so.1" – Stasik Jun 14 '13 at 08:22
Edited my answer (see the `objdump` line at the end). – Matthieu Rouget Jun 14 '13 at 08:29
yea! thats it, if you replace LD_LIBRARY_PATH by LIBRARY_PATH, I will accept the answer! – Stasik Jun 14 '13 at 08:31
Yes you are correct. `LIBRARY_PATH`is for the linker, `LD_LIBRARY_PATH` is for.... `ld`. Will fix it. Thanks. – Matthieu Rouget Jun 14 '13 at 08:33

Linux linking a shared object

1 Answers1