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 <[email protected]> _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
