[OpenIndiana-discuss] How many versions of libs/apps should OI provide?

[James Carlson]

On 12/22/16 13:14, Jay F. Shachter wrote:
> of a library.  But this question can only arise with respect to
> binaries, because libraries contain version numbers, so that
> whizbang.so.1 and whizbang.so.2 can coexist on the same system.  With
> respect to header files, two versions cannot coexist on the same

"Can" is sort of a strong word here.

Versioning by soname rather than having a single binary using #pragma
redefine_extname is extraordinarily dangerous, as the libresolv.so.2
fiasco proved quite some time ago.

If your library is unpopular and used only in one place, then you might
be able to get away with this.  But if the library is at all useful and
interesting, you run into a really horrible dynamic linking trap.

The trap is this.  Suppose you have an application that depends on
libfoo.so.1.  It links with libbar.so.1 that also depends on
libfoo.so.1.  All's well so far.

Now we deliver a new libfoo.so.2.  The guy who maintains our application
is a real go-getter, so he relinks and redelivers binaries almost right
away.  When the application runs, it pulls in libfoo.so.2 and (via the
libbar.so.1 dependency) pulls in libfoo.so.1 as well.  Oops.  Chaos
ensues.  You get SIGBUS and an extremely confusing to examine core dump
if you're lucky, or silently corrupted user data if you're not.

OK.  Suppose our application developer is a slacker who doesn't
redeliver quickly, but the libbar guy is on the ball.  The same thing
happens.  We end up with libfoo.so.1 and libfoo.so.2 in the same address
space, competing with each other for bindings.

Suppose that all of these guys somehow deliver synchronously.  Sadly,
we're still not out of the woods.  If the application (or *any* of its
dependencies) has any sort of plug-in mechanism -- e.g., to enable
IPR-protected features at run time, then we're vulnerable through that
mechanism to pull in incompatible library versions at run time.  In
short, you have to relink and redeliver the whole Universe
synchronously.  That's cool if you deliver only as source code and your
customers compile from scratch, but much less so if you ship binaries.

The bottom line we found at Sun (and ended up enforcing everywhere) was
that versioning via sonames just plain doesn't work in the real world.
It's a humorous idea, and I'm sure it gives developers on other
platforms endless hours of dynamic linking entertainment, but it doesn't
quite fit with a robust product.

That's why you'll see all those redefine_extname and #define renames all
over the core source base.  They allow a *single* library binary
instance to deliver *multiple* coherent bindings to different consumers.
 It's hard to do, but the results are (in my opinion) worth the effort.

I realize that there's nobody around who can do the same sort of work
required for upstream open source suppliers.  When I was at Sun, we did
try to build walls around the worst offenders in this area (OpenSSL, I'm
looking right at you), but it's a thankless task at best.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>