LSB summit -- +/- OT

James Richard Tyrer tyrerj at acm.org
Mon Jun 19 06:31:42 BST 2006


Thiago Macieira wrote:
> James Richard Tyrer wrote:
>> So, it appears that the solution to this problem would start with
>> LibTool and isn't really a LSB issue.  It would also appear that it
>> would be better if LD.SO could deal with something linked against, for
>> example, 2.8 and it would find 2.8.6 without needing an additional link:
>> glib.so.2.8 -> glib.so.2.8.6.
> 
> There's nothing wrong with LSB or ld.so here. It already supports what you 
> want.

Not suggesting that there is anything wrong with LD.SO and I said that 
his isn't really an LSB issue.  I do, as I said, see an issue with 
LibTool here.

LD.SO could include additional features to deal with the issue.  E.G. if 
all you needed to do was install the specific version of the libs with 
the same <prefix> as the app and LD.SO took care of it, that would be 
real nice.  The effect would be the same as if you set: 
"LD_LIBRARY_PATH" to <prefix>/lib.  Just an idea.

> It's the developers of said libraries that promised to keep binary 
> compatibility but didn't. Every time that happens, you're entitled to 
> send them bug reports so that they fix their problems.

Yes, I agree that these problems shouldn't happen.  But, the fact is 
that they do happen and something needs to be done about it.  Yes, I 
would like things to be the way they *should* be, but engineers are 
pragmatists -- the problem does exist and we should consider ways to 
deal with it rather than wishing that it didn't exist.

> The same applies to behaviour changes as well, as long as you weren't 
> depending on broken behaviour.

That is an interesting question since it appears that the GLib problem 
only affect aRts and apps that use aRts.  AFAIK, the problem doesn't 
happen with GNOME apps.  If this is true, then aRts probably was 
depending on "broken" behavior.

IAC, in Windows this problem is serious; is called DLL hell.  It would 
be nice if Linux had a simple way to deal with the problem -- and we can 
deal with the problem since libraries for Linux all have version numbers.

-- 
JRT





More information about the kde-core-devel mailing list