[lug] Need help understanding linking and loading shared libraries

[Hugh Brown]

>>> I went poking around and couldn't find out how ld.so decides what the name of the library is to embed in the executable.  I was looking in the context of how ldconfig decides what to name the links it creates.  I also noticed on my debian system that libboost has a variety of very convoluted names (which embed, compiler, threading, etc. info into the name of the library) which may be causing the problem.
>> I've learned that when you build the .so file you can use a parameter
>> "-soname foo.so.1", so that even though you've built foo.so.1.2.3, it
>> will respond to foo.so.1.  I think when the boost I have was built it
>> didn't get the -soname parameter.  Building boost looks interesting,
>> but maybe I'll have to learn it.  Or maybe I can learn to live with
>> the full name.
>>
>> I haven't seen any way to query a .so file to find out it's "-soname" setting.
> 
> Hah.  Now that I know what to look for I found it rather quickly:
> bash$ objdump -p /usr/X11R6/lib/libGL.so.1.2 | grep SONAME
>   SONAME      libGL.so.1
> 
> I ran this on my real boost library, and sure enough, the soname
> included all the version info.  No big surprise--after all this I
> pretty much expected that.
> 
> Michael

Thanks for following up on what you found.  Based on what I read in the 
Debian.README file for libboost-python, it sounds like the boost 
community prefers the really long library names that contain all the 
info about how it was compiled.

Hugh