On 12/29/16 17:24, Jim Klimov wrote: > 29 декабря 2016 г. 22:25:23 CET, Bob Friesenhahn > <bfrie...@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 <carls...@workingcode.com> _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
