CODEWITHSUNDEEP
clinuxshared-librariessymlink
Robin92
Robin92

Reputation: 561

Symbolic link weird issue

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

Upvotes: 0

Views: 377

Answers (1)

MvG
MvG

Reputation: 60858

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.

Upvotes: 3

Related Questions