The Licquia Blog

For background, read part 1. This post is going to get a bit technical, so if the first part made your eyes gloss over, you might want to skip this part.

So our goal is to provide an LSB-compatible environment for LSB programs, and an environment compatible with Debian 3.1 for the rest. It seems that we can’t do this using the same system libraries and programs, so we need to use different ones. But how do we convince one environment or the other to load when we need them, and not to load when we don’t?

The key is the dynamic linker: that magic code that finds the shared libraries for the programs we run and puts them all together so the program can find them. It turns out that the LSB insists on having its own dynamic linker, separate from the rest of the system; runtime environments can’t be LSB-compliant without them, and programs can’t be LSB-compliant unless they use the special LSB linker. The linker doesn’t have to act any different from the normal one, so standard procedure is to symlink the regular dynamic linker to the name the LSB requires.

But the possibility has always been there to use an entirely different linker for LSB programs than for non-LSB programs, and even to use different linkers for different LSB versions. So, the solution is obvious: instead of symlinking the standard linker, we provide a slightly modified linker for LSB programs.

What do we mean by “slightly modified”? One possibility: cutting-edge versions of libraries could be stored in a separate location on the system, where no regular application will see them. Our LSB linker could then prefer libraries from the special paths to the normal ones. Another: programs which must run differently under the LSB can be compiled differently and live in their own special location, which are preferred to the normal location when run in the LSB context.

So far, this is vaporware. I’m still wrestling with the source code to glibc to see how difficult it would be to do this. Once done, however, LSB compliance and compatibility with Debian might no longer be conflicting goals.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.