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

Dallman, John john.dallman at siemens.com
Fri Sep 12 08:22:21 PDT 2008


> On Fri, Sep 12, 2008 at 12:57:47PM +0200, Dallman, John wrote:
> > I agree that not changing the soname makes it simpler this time
> > round. But if we find that it needs to be changed for LSB 5, and
> > then not again until LSB 8, or whatever, things start to get
> > confusing. That's why I'm arguing for maintaining the current
> > pattern unless there's a major positive reason to change it.
> 
> Sure, but think about it --- why would we ever need to change the
> soname? Traditionally, the only reason to change the soname is if
> there is some fundamental breakage, such as changing a structure ...

I don't know. But I am not keen to make the assumption that you, 
or I, or anyone else, can anticipate all of the possible reasons 
why this might be needed. 

> We've never *needed* to change the soname in the entire history of the
> LSB (we bumped it out of superstition more than anything else),

Following this argument to its endpoint, you could claim that 
the whole ld-lsb loader was unnecessary. That suggests that one 
final change should be made, to remove it entirely. 

However, are you keen to give up the possibility of handling 
unpredictable future situations that it provides? I am not.

> the ld-linux.so major version has never been bumped in the entire
> *history* of glibc2 --- and glibc2 has been stablizing and the number
> of changes in glibc in general has been slowing down.

Indeed it has. However, what happens when someone wants to create 
glibc3, and convinces people that there is some adequate benefit 
for so doing? 

> The only thing that I could imagine requiring ld-linux.so changing a
> major version (which would also drive ld-lsb.so major version) would
> be a complete changeover from ELF to some other incompatible linking
> format, which is pretty unlikely --- and if it did happen, it would be
> such a major incompatible change, that would involve major breakages
> all around the , debugging, and build chains, not to mention breaking
> all sorts of internal LSB infrastructure --- the soname change will be
> the ***least*** of the confusion.  I also believe this is so unlikely,
> because of the absolute hell that it would drag the entire Linux
> ecosystem through --- that it's really not worth planning changes
> around this remotely unlikely possibility.

I refer you to the change from libstdc++.so.5 to libstdc++.so.6. That
was not as drastic as a change of linking format, but it required us
to treat "before" and "after" Linuxes as potentially both-ways 
incompatible, and required a complete refresh of all the C++ 
components we use. Not a major problem if it's all stuff you have 
the source for. A big problem when you have binary-only libraries 
from over a dozen manufacturers, with widely varying attitudes and 
schedules for a switch-over. And if the LSB isn't about allowing 
this kind of thing to happen, what is it for?

-- 
John Dallman
Parasolid Porting Engineer


More information about the lsb-discuss mailing list