[lug] Need help understanding linking and loading shared libraries

[Michael Hirsch]

On Feb 5, 2008 9:13 PM, Michael Hirsch <mdhirsch at gmail.com> wrote:
>
> On Feb 5, 2008 9:28 AM, Hugh Brown <hugh at math.byu.edu> wrote:
> >
> > On Tue, Feb 05, 2008 at 09:04:20AM -0700, Michael Hirsch wrote:
> > > On Feb 4, 2008 6:28 PM, Hugh Brown <hugh at math.byu.edu> wrote:
> > > >
> > > > Michael Hirsch wrote:
> > > > > I thought I mostly understood this, but I'm definitely missing something.
> > > > >
> > > > > I have a library, lets call it libboost.so.1.33.1, though the real
> > > > > name is longer.  There is also a copy of this file named libboost.so
> > > > >
> > > > > I build my own library, lets call it libfoo.so which relies on
> > > > > libboost.  The option to g++ is -lboost.
> > > > >
> > > > > Finally, I have an executable, bar, that needs libfoo.so (again, with -lfoo).
> > > > >
> > > > > All this works.  But now, if I only have libboost.so and not
> > > > > libboost.so.1.33.1 the loader will complain that it can't file
> > > > > libboost.so.1.33.1.  In fact, "ldd bar" reports libboost.so.1.33.1,
> > > > > rather than libboost.so like I expected.
> > > > >
> > > > > I was under the impression that since libboost.so satisfies all the
> > > > > link requirements for libfoo, that it would satisfy the loader.  Is
> > > > > there something I've have done that makes libfoo.so know the exact
> > > > > version number of the libboost.so library?  Is there a way to turn off
> > > > > this exactness requirement?
> > > > >
> > > > > I expect I'm missing some seemingly trivial but crucial information,
> > > > > but don't know what that is.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Michael
> > > >
> > > >
> > > > Usually libboost.so is a symbolic link to the versioned library.  So if
> > > > you link in -lboost it will use the target of the symbolic link (i.e.
> > > > libboost.so.1.33.1).
> > >
> > > Yes, I knew that.  But I believe that if, instead of linking, I just
> > > rename libboost.so.1.33.1 to libboost.so, it should be able to use the
> > > shorter name. I thought that was the whole point.  It allows the
> > > system to have a minor upgrade to, say, libboost1.33.2 and still
> > > resolve all the symbols.
> > >
> > >  Apparently not, or not without some additional work.
> > >
> > > Michael
> >
> >
> > 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