[lug] Need help understanding linking and loading shared libraries

[Michael Hirsch]

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.

Michael