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

[Dallman, John]

> Some ISV's have different executables for different distributions, 
> but most agree that this is a real pain in the you-know-where.

I work for an ISV in porting and platform support, and that's 
the exact reason that we're interested in LSB at all.

> 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 empirical
> testing has shown that if is built on an old system, it will work on
> newer systems, on both on SLES and RHEL.

We don't work quite like that. We do have a well-defined build platform,

which we keep stable, but we refuse to have it be a machine that we
can't 
reconstruct if the existing one breaks down. That means that,
eventually,
we have to move up. 

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

We haven't found that to be a problem with the product I work on, but 
it doesn't make all that much use of any libraries, being essentially
a math library. The main app that this library of mine forms part of 
is not LSB-compliant, because it uses Motif.

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

Yup. But it should be noted that ISVs will continue to *check* what 
works and what doesn't, even if someone sets up to provide them this
information. Unless someone is providing that information on a basis 
that if it turns out to be wrong, they'll get it fixed, for certain,
on a timescale of weeks or less, it *has* to be checked. 

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

That is what is causing us to have to move up: from SLES9 to SLES10
in our case. 

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

This seems perfectly OK to me. 

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

The idea of needing to have the LSB loader in place to run LSB apps 
doesn't seem like a big issue to me, but I probably have more 
cooperative sysadmins than many end-user sites. 

> 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 any LSB certified distribution.  
> That way, if a customer shows up, and says, "we *must* have 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.

I'm not precisely clear on why this is better than the current 
situation, where the LSB loader is normally a softlink, but can 
do work if it needs to do so. Could you explain a bit more? 

Is it that the trampoline code inserted by lsbcc is easier to have 
portable between distros than an loader written by the LSB? 

Is it just the lack of need for an lsb loader softlink? 

Or something else? 

thanks,

-- 
John Dallman