Re: obsoleting shlibs - what's the plan

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Mar 26, 2008 at 06:32:48PM -0400, der Mouse wrote:
 > >>> (e.g., if .so.3.1 arrives we can remove .so.3.0, but not .so.2.1).
 > >> I believe we should, these old and new libraries do not coexist
 > >> nicely.
 > > I don't understand.  Which kind of problem arises?
 > >   programs linked against the old major won't dynlink right
 > >   programs linked against the old major won't do the right thing
 > >   new programs won't link right if the old major is present
 > >   programs linked against the new major won't dynlink right
 > >   programs linked against the new major won't run correctly
 > 
 > Seems to me that any of these, if true, are critical bugs in our shlib
 > implementation - isn't that kind of disambiguation exactly what major
 > version numbers exist for?

So you'd think.

In practice, you can in some circumstances end up with multiple major
versions of the same lib loaded at once, and with standard ELF that
pretty much inevitably results in nasal demons.

This is what can happen:

Starting point:

   app uses libwowiezowie.so.1
   app uses libkrb5.so.20
   libwowiezowie.so.1 uses libkrb5.so.20

This works. But now suppose I recompile libwowiezowie:

   app uses libwowiezowie.so.1
   app uses libkrb5.so.20
   libwowiezowie.so.1 uses libkrb5.so.21

Running the app will now load both kerberos libraries. This probably
won't work - if the app and libwowiezowie use Kerberos completely
independently from one another it might in principle, but that's
probably not the case, and passing objects or handles allocated by
libkrb5.so.20 to libkrb5.so.21 will, in general, blow up. (Also the
two copies might fight with each other over "process-private"
resources, and other fun stuff.)

Note that recompiling the app and not libwowiezowie produces symmetric
and equally fatal results; you need to recompile both or neither.

However, it's even worse than this - with standard ELF, once you get
two copies of the same library loaded you lose instantly, because the
ELF dynamic linker binds only by symbol name, and it doesn't notice
duplicates. So all libkrb5 symbols used in the running image
(regardless of whether they were referenced by the app or by
libwowiezowie) will be resolved to whichever version of libkrb5 the
dynamic linker happened to pick up first. The other one will be
ignored. This will, in general, blow up regardless of whether two
copies of libkrb5 could in theory successfully operate at once.

The "symbol versioning" system Linux uses, because it's really not
just *symbol* versioning but a complete replacement ABI versioning
system with less broken semantics, solves the second problem. However,
our dynamic linker doesn't support it - and even if it were made to,
there still isn't any solution to the first problem.

(You can't even quite work around the problem by bumping
libwowiezowie's major version - that will work if you recompile
libwowiezowie first, but if you recompile only the app, you still get
wrong behavior.)

-- 
David A. Holland
dholland%netbsd.org@localhost