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

Dallman, John john.dallman at siemens.com
Thu Sep 11 07:03:31 PDT 2008


> I think the confusion factor is very overrated.  Seriously, *who* is
> going to be confused?

People who aren't working simply in the categories you suggest, and 
people who are having to cope with situations with partial information.

For example, how does one tell if a binary sans documentation is an 
LSB one, and if so, what version? There are multiple ways that I know 
of, but they all rely on the linker string. Real-world computing 
doesn't always fall into neat categories. 

> Application developers?  They use our tools, and in fact having two so
> names makes life *more* confusing, since if they have an application
> that can work on LSB 3.2 and LSB 4.0 certified distributions, they
> need to link against ld-lsb*.so.3; but if they are using symbols that
> are only present in ld-lsb*.so.4, then they had better link against
> ld-lsb*.so.4.  So being able to determine that correctly means more
> complexity in our tools, or forcing application developers to get that
> part right, which I would submit is multiple orders of magnitude more
> confuisng.

I disagree. One sets up one's toolset for LSB 3.x or 4.0, and leaves
those settings - environment variables in login script, or whatever -
alone. 

> Distribution developers?  Their build scripts already install one
> symlink.  Making this change means they will need to actually go in
> and make additional modifications, and given that a distribution will
> want to support LSB 3.2 and LSB 4.0 applications at the same time (why
> not, it's easy for them to do so), they will need to install both
> symlinks.  But if some distro's get this wrong, and only install
> ld-lsb*.so.4., that will mean even more confusion for end users.

Are there other changes they need to make? Leaving out a simple
and easily comprehensible one risks them concluding "No, nothing 
needs to change". 

If you want ISVs to actually use LSB, consistent behaviour and 
simple rules without special cases are important. I work with six
different operating systems, where all of Linux is only one of 
them. Using up lots of brain-space on special cases is just 
unhelpful.

Of course, if it weren't a special case, and it was likely that 
there would NEVER be a need for a different linker, that's quite 
different. How probable do you feel that is? 


-- 
John Dallman
Parasolid Porting Engineer

Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: +44-1223-371554
john.dallman at siemens.com
www.siemens.com/plm

> -----Original Message-----
> From: Theodore Tso [mailto:tytso at MIT.EDU]
> Sent: Thursday, September 11, 2008 2:30 PM
> To: Robert Schweikert
> Cc: Dallman, John; lsb-discuss at lists.linuxfoundation.org
> Subject: Re: [lsb-discuss] lsb dynamic linker name for LSB 4.0
> 
> On Thu, Sep 11, 2008 at 08:00:22AM -0400, Robert Schweikert wrote:
> > I agree with John. While there may be no strong technical reason to
> push
> > the number forward, the confusion factor this will introduce is
> > potentially quite large.
> >
> > We promise backward compatibility but not forward compatibility. It
> is
> > inevitable that people working to qualify w.r.t. 4.0 will
> wonder/worry
> > about why the linker name indicates version 3 and how this effects
> > compatibility.
> 
> I think the confusion factor is very overrated.  Seriously, *who* is
> going to be confused?
> 
> Application developers?  They use our tools, and in fact having two so
> names makes life *more* confusing, since if they have an application
> that can work on LSB 3.2 and LSB 4.0 certified distributions, they
> need to link against ld-lsb*.so.3; but if they are using symbols that
> are only present in ld-lsb*.so.4, then they had better link against
> ld-lsb*.so.4.  So being able to determine that correctly means more
> complexity in our tools, or forcing application developers to get that
> part right, which I would submit is multiple orders of magnitude more
> confuisng.
> 
> Distribution developers?  Their build scripts already install one
> symlink.  Making this change means they will need to actually go in
> and make additional modifications, and given that a distribution will
> want to support LSB 3.2 and LSB 4.0 applications at the same time (why
> not, it's easy for them to do so), they will need to install both
> symlinks.  But if some distro's get this wrong, and only install
> ld-lsb*.so.4., that will mean even more confusion for end users.
> 
> So I just don't see the upside in making the soname change.  Just lots
> of downsides.
> 
> 						- Ted


More information about the lsb-discuss mailing list