One of the best/worst Microsoft software innovations (great for compatibility; terrible for efficiency) has been Windows’ Side by Side Configuration. This allows, among other things, for different components of a program to have multiple versions of the C/C++ runtime libraries loaded into the same process.
This has always impressed me because of the excellent backwards compatibility that it affords. For example, you can run an ancient program that links against very old C/C++ runtimes, and link it against or dynamically inject a new DLL that depends on a new C/C++ runtime, and all the separate instances of the runtimes will coexist simultaneously within the address space and will be called by the assembly that references them.
On Linux, however, binaries for which the source is not available tend to “rot” over time — rather quickly. The reason is that most interesting programs eventually have to link back into libraries that are installed in your system directories (/usr/lib, etc). But since the C/C++ runtimes and the system libraries frequently change ABI, your program just stops working when you upgrade your distro.
This can also be caused, for example, by software with “backends” that eventually link to your system libraries. An example is OpenGL, which due to the variety and volatility of the implementations, cannot be provided by binary distributions. They simply must depend on the system’s OpenGL implementation.
But if your system OpenGL links against libstdc++, you could potentially be dead in the water. What happens is that the old executable loads its local copy of libstdc++, and the OpenGL shared library loads the system’s copy of libstdc++. The two conflict, and one of them refuses to load, and usually this means that OpenGL refuses to work and the program comes crashing down.
For a “mere” application developer, is something like WinSxS achievable on Linux without major architectural changes to the ELF binary format and Linux kernel ABI? Or is this something that would have to be built into the system libraries at compile-time and deployed over a long period of time by making changes to ELF, glibc, libstdc++, compilers, and so on?
This may be foreign to Windows developers, but the solution is to provide the source, and recompile when the ABI changes. You don’t even need to provide all the source, just compile a wrapper on the interfaces that are likely to change, and link it with a binary holding the proprietary stuff. Think of it as creating your own stable ABI. Nvidia has been successfully following this model forever. There are tools like DKMS that help make the recompilation process essentially invisible to the user.
If your product is popular enough, the community will even help you maintain the wrapper when the API changes. For example, I ran community patches for Nvidia’s driver before their official updates for kernel 2.6 were released.
Admittedly not as easy as just having your own library files for everything, but then again, for most applications it is as simple as that. The wrapper solution is only necessary for a subset of software that’s fairly low level.
2