[lsb-discuss] Another way of supporting the ld-lsb.so.3 dynamic loader

Theodore Ts'o tytso at mit.edu
Tue Mar 11 12:54:56 PDT 2008

One of the topics that came up at the ISV meeting last week is that the
lsbcc might be a useful tool for generating binaries that work across
multiple distributions.  Some ISV's have different executables for
different distributions, but most agree that this is a real pain in the

So for those that try to have a single executable for all distributions,
what some of those ISV's do is to use a very carefully tended, antique
build machine that can boot some old version of SLES8/SLES9, RHEL3,
etc., and build their product on that ancient system, since emprical
testing has shown that if is built on an old system, it will work on
newer systems, on both on SLES and RHEL.  Of course, extensive testing
is done on the actual target distribution before they release; the
ancient version of SLES/RHEL is simply used as the build system, not the
test system.

There are only a couple of problems with this scheme.  (1) it requires
the use of the compat libraries, which may not have as much performance
and functionality as the newer libraries, especially as far as glibc is
concerned, (2) this isn't a supported use by the distro's, and so each
ISV has to rediscover what works and what doesn't on their own, and (3)
the older distro's don't support the latest hardware, which means they
have to use older/more expensive/harder to maintain hardware for their
product build engines.

As it turns out, lsbcc could be used to provide much value to ISV's,
since it could provide the same functionality, without requiring them to
continue using an old system, but for the fact that it changes the ELF
interpreter from ld-linux.so to ld-lsb.so --- and a number of
distributions, do not install the lsb package and so do not have the
ld-lsb.so -> ld-linux.so symlink present by default.

So --- what to do?  One approach would be to get rid of the ld-linux.so
interpreter altogether, as it has only been used exactly once, and the
scenarios where you might use it are admittedly rare and someone exotic.
However, in discussions with Jeff, I came up with a way which I think
would actually be better.  What we do is we change things so that we let
the ELF interpreter be ld-linux.so, since that's what's present on all
systems.  *However* we then have lsbcc add code, either in the .init
section before any other static constructors have a chance to run, or in
crt1.o itself, which adds a short instructure sequence which attempts to
stat() (NOT lstat) the ld-linux.so and ld-lsb.so files to see if they
are identical.  If they are, the program execution proceeds as normal.
If they are different, then this trampoline code will exec the ld-lsb.so
file with argc/argv set up appropriately so it can run the application
using the LSB dynamic linker.

What does this buy us?  It means that in the normal case in an LSB
environment, where the ld-lsb.so file exists and is a symlink or a
hardlink to the ld-linux.so file, the cost in execution time is only two
stat calls, for two inodes that will almost always be in cache.  So the
cost to this case is almost nothing.  If we ever *do* need to use it as
an escape hatch, the cost will be that the interpreter will need to run
twice, which will burn a little CPU time, but only for those
ISV-supplied applications, many of which are long-running applications
and not something like "/bin/cat" that might be used many times from a
shell script and where startup time could dominate the execution time of
the process.

It also means that an application which is built in this way will
usually work on most distributions even if the ld-lsb.so file isn't
present.  It won't be guaranteed to work, of course, since without the
LSB module being loaded some dependencies might not be present as well.
But in vast majority of the cases, it *will* work, and for at least some
ISV's, since they intend to test their application on each distribution
before they say that they will provide enterprise-level support, what
this means is that the LSB build environment would provide real value to
them, since this would allow them to build their product executables
once on a modern system, and then take that executable and test it on
those distributions they support.  What we would tell them is that even
with the LSB link, it is highly likely that an executable produced with
lsbcc, will work on on any LSB certified distribution.  That way, if a
customer shows up, and says, "we *must* your your application on
Mandriva/Red Flag/Ubuntu; here's a six-figure check", even it gives the
ISV an opportunity to take their the lsbcc produced binary, run their
regression check, and then cash the customer's check.

Anyway, that's the basic idea.  What do people think?  If we think this
is a good idea, there are a host of details we would have to iron out,
including exactly where we would put the new code to stat and perhaps
re-exec the program using ld-lsb.so, and what text we would need to put
in the LSB specification (as an optional alternative) and how we would
test for a proper result in the appcheck.

							- Ted

More information about the lsb-discuss mailing list