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

[James Carlson]

On 12/29/16 17:24, Jim Klimov wrote:
> 29 декабря 2016 г. 22:25:23 CET, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> пишет:
>> On Thu, 29 Dec 2016, James Carlson via openindiana-discuss wrote:
>>> 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.
>>
>> At least Linux supports versioned symbols and libjpeg (and some 
>> others) were adapted to use versioned symbols so that multiple major 
>> versions of the library could be pulled in at once without harm.
>>
>> Does Illumos support Linux-style versioned symbols?
>>
>> Bob
> 
> Bob, do you mean symbols like 'this requires SUNW_1.23'? Yes, these are here too. I believe they do not quite work around the issue James describes, e.g. when your running binary pulls two copies of different libjpeg.so.* even with proper versioning. For example, if a library uses some global variables for state-keeping, and you call a random set of functions from one and another copy of the loaded lib that both satisfy your older required ABI version, you can get chaos. @James, is this a correct interpretation? ;)

That's close.  The problems are many and end up being complex because
you can't rename the entire Universe.

One way that things go south is by having objects shared in some way
between the variants.  This can happen by (for example) having the
application allocate an object of type Foo.1, and then handing it to a
library that is bound to something using Foo.2.  Unlike some
environments (such as Java), there's no run-time type validation in the
binary world.  In short, if anything other than integral types get
passed around, there's the hazard that passer and passee disagree on
version.

Another way things can go wrong is with external resources, such as
files (particularly, but not limited to, lock files), shared memory
segments, and network connections.  It's not uncommon that a library
"assumes" that it is the only instance of itself within a given process,
and it's shocking when there are duplicates that shift the sand below.

It's possible that a sweeping rename might well have helped with the
libresolv.so.2 problem (if I recall enough of the failures correctly),
but I don't think it's a robust answer.  The robust answer is just never
breaking compatibility, which requires a nontrivial amount of
engineering effort.  (Part of which, naturally enough, goes into the
initial creation of interfaces that aren't so crappy that they need to
be broken in the future.)

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