Question

I’m messing around with Linux’s shared libraries and encountered strange issue. I successfully create a shared library and get librbmp.so.0 file and then symlink it getting two more files: librbmp.so and librbmp.so.0.0.1. Then I copy ’em to /usr/local/lib and run ldconfig and here I meet with a strange behaviour – one more file appears in /usr/local/lib. It’s called --library=ibrbmp.so.0.0.1. What’s strange, my application links to it during runtime.

Anyone know what’s happening and how to force my app to link to librbmp.so?

Here’s a piece of code:

//creating shared library
$(CC) -shared -Wl,-soname,-librbmp.so.0.0.1 $(OBJECTS) -o librbmp.so.0 -lc

//symlinking
ln -sf librbmp.so.0.0.1 librbmp.so.0
ln -sf librbmp.so.0.0.1 librbmp.so

Answer 1

The name your application uses at runtime is embedded in the library at link time. So something in your build process introduced a strange command line argument to the linker.

When using gcc as your linker frontend, I assume that the argument should have been -Wl,-soname=librbmp.so.0. In your call, the extra - is probably the cause of the problem. It seems that something rather stupidly translates all instances of -l into --library= before invoking the actual linker, which will then see -soname=--library=ibrbmp.so.0.0.1.

Also notice that the soname usually should specify the form indicating the api level compatibility. So in your case, the soname should be librbmp.so.0 and the actual output object file be librbmp.so.0.0.1. That way, you can increment the version when you improve your library, and as long as you don’t break binary compatibility, your applications will still work. When you break ABI, you should bump the soname to librbmp.so.1 and so on.