[lsb-discuss] lsb dynamic linker name for LSB 4.0

[Theodore Tso]

On Mon, Sep 15, 2008 at 09:47:06AM -0400, Robert Schweikert wrote:
> It is true that a developer using the LSB tool chain from beginning to  
> end will not see the name of the dynamic linker and couldn't care less  
> what we call it and why we have it. However, IMHO the assumption that  
> this is the best way into LSB compliance from an app point of view is  
> incorrect. Turning lsbcc loose on a large app is just not feasible as  
> the failures would simply be overwhelming. Rather, it appears to me that  
> a more moderate transition of build with existing tools and then run  
> appcheck  allows app developers to address issues one library at a time.  

I disagree, and the reason why I don't think this is using existing
tools is a long-term workable approach is ELF symbol versions.  If a
particular version of LSB (say, 4.0 for the sake fo argument), is
based around version 2.5 of some library (e.g glibc), and the
distribution is based around version 2.6, then if they link against
the 2.6 version of the library, even if they use the functions that
are in the LSB, they may end up using a newer version of the ELF
symbol version than what will be in LSB 4.0 and the 2.5 version of the
library.  The reason for that is the most library maintainers only
makes the forward compatibility guarantee that an application linked
against 2.5 will work on 2.6, 2.7, 2.8, etc., but an application
linked against 2.6 will not necessarily work against a 2.5 library ---
and there is no guarantee whether an LSB 4.0 certified distribution
might be using a 2.5, 2.6, 2.7, or even newer version of the library,
as long as it provides all of the functions and ELF symbol versions
guaranteed by the LSB.

And I don't think it is fair to assume that ISV's will be able to
track which version of each LSB-mandated library is being used by
their distribution of choice and how to create the approriate ELF
symbol map files in order to force the use of the right symbol
version.  :-/

I understand your concerns about it being too hard for ISV's to use
the lsbcc, but to me that says we need to find easier ways of making
lsbcc easier to be used by ISV's.  For example, you have pointed out
correctly that many application programmers find chroot's to be
unusable for a variety of reasons; and the new LSB build environment
was intended to address some of them.  However, long term we probably
need to do more in this area.  For example, can we take our header
files and stub libraries, and combine it with an install script that
examines a distribution's gcc spec file, and creates a modified spec
file that uses our header files and stub libraries, and then creates a
wrapper program?  In theory it should be doable, such that people
could run lsbcc out of their ~/bin.

This is something that I think we need to focus on much more post LSB
4.0, to solve such issues.  But I don't believe that in the long run
expecting ISV's to read through the LSB spec and then figure out how
to create LSB-compliant binaries on their own using the standard
distribution's tool chain is going to be a long-term viable solution.

Regards,

						- Ted