Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

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.

share|improve this answer
    
I'm aware of (and approve of) the interface wrapper paradigm for Nvidia and AMD drivers, and I'm also a huge advocate of FOSS. What I was hoping for is an answer that would help proprietary software developers (e.g. game developers) extend the duration that their software can run without the developer's intervention on Linux. It seems like the interface wrapper paradigm could work also for userspace programs, if done properly. Very interesting. But how would you do this for, e.g. libstdc++? One little change and all the symbols get mangled, etc. Sounds very messy to translate. :S –  ÃŁŁǫǛȉЖΦΤїҪ Aug 13 '12 at 20:20
    
And by "extend the duration that it can run" I mean "on the latest release of Fedora", for instance, since Fedora is always updating to the latest version of packages and breaking APIs/ABIs as they go. –  ÃŁŁǫǛȉЖΦΤїҪ Aug 13 '12 at 20:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.