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

[Wichmann, Mats D]

> 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. 

I'm okay with this in principle, but as always questions... (as you
say, there are lots of details).

The LSB "alternate linker name" thing is ancient, of course.
As defined, it serves two purposes:

1. provide a hook for a distribution to do something different.

2. provide a quick was to identify that this application is
*intending* to target LSB, and indeed, a particular major
version of LSB.

Both of those can be handled in other ways.  The trampoline
trick described in this message covers #1.  Note that at one
time it was thought this hook would be useful for non-Linux
systems implementing an environment that could run LSB 
applications.  I think it likely would make that much harder,
but I'm not sure it's important any longer.   None of those
emulator environments have appeared in the ten years or
so LSB has been active (although there were rumors for a
while), and the rise of virtualization support means if
you want to run Linux apps you could run a VM with Linux.

I'm not eager to teach lsbappchk to go digging through
assembly code to find the embedded string for the LSB
linker and use that to identify that this is an LSB binary.
But we could consider something else - there are other
places in the ELF headers that could hold information,
in particular the not-used-for-execution NOTE sections.

As has been said elsewhere, the idea that if the LSB linker
is present, then this is an LSB system is an imperfect one
anyway.  The presence of the linker *probably* indicates
that it once was, because it probably came in by way of
installing a keystone package which depends on all the
other packages needed to make sure the environment is there.
But it's not required to be implemented that way, and
even if it is, something could have changed later. Indeed,
the LSB linker might be there only because somebody got
bored with stuff not working and made a symlink by hand. So
I'm not sure we lose *all* that much by effectively saying
we don't require the linker to be present any longer on
a distribution.