LSB summit -- +/- OT

[Thiago Macieira]

James Richard Tyrer wrote:
>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.

There's also nothing[*] wrong with libtool. It is doing what it's supposed 
to. It's not its fault that it's being misused. It's really, really 
simple: if you break binary compatibility, you reset your "compatibility" 
count to 0.

[*] besides being one big shell script that takes more time to run than 
the linking itself.

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

This is called DT_RUNPATH and is supported too. But you're not supposed to 
require "the version of the library that I shipped". You're supposed to 
require "library X version N" and *any* such library should be ok.

If library X can't maintain binary compatibility (OpenSSL comes to mind), 
then you have to invent a creative new way of doing that. For the OpenSSL 
case, we dlopen(3) it so that we can first test which version we found.

>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 only solution to breaking binary compatibility is to modify the 
soname. It isn't that hard and it's a very simple solution.

If Trolltech and KDE can maintain binary compatibility in huge C++ 
libraries, other projects can do the same in C.

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

I agree.

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

What could be a good idea is to have a nice tool out of LSB that compares 
two libraries and decides if they are binary compatible to one another.

That isn't an easy task, though. I sat beside Harald Fernengel when he was 
preparing the LSB table descriptions of the Qt4 libraries and that was no 
easy task. It also included a fair amount of subjective filtering to 
decide "this symbol is private, despite being exported" and drop them 
from the listing.

-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech ASA
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060619/7a20793b/attachment.sig>