LSB summit

James Richard Tyrer tyrerj at
Tue May 30 02:24:11 BST 2006

Thiago Macieira wrote:
> James Richard Tyrer wrote:

>> This makes one wonder about the binary incompatibilities in GNOME 2.14.
>>  How does the LSB deal with this?  Specifically: GLib 2.8.x vs. 2.10.x
>> and GTK+ 2.8.13 vs >= 2.8.14.  Is this an issue, or did GNOME just make
>> a big mistake that they need to correct?
> I'm not sure you're grasping correctly what binary (in)compatibility is, 
> judging by your comments.

Sorry for my brief comments.  I can right a book if you want. :-)

The Thunderbird binary version Acrobat Reader 7.0 work correctly 
with GTK+ version 2.8.13 but if you upgrade GTK+ to version 2.8.17 they 
fail to start and report an error.  I presume that this is binary 
incompatibility.  It also breaks Firefox which I built from source and 
don't know if rebuilding against the new version will fix it but it will 
still be a binary incompatibility.

> If we go down to the lowest level, binary compatibility is such that no 
> symbol that previously existed and was public ceases to exist and the 
> layout of any data structures remain the same. 

And that gets to the second point.  If you have GTK+ version 2.8.13 and 
GLIb version 2.8.6 installed from binaries and you want to upgrade to 
GTK+ version 2.8.17 you are going to have to have some dependency 
tracking other than just the LSB version since GTK+ version 2.8.17 
requires GLib version >= 2.10.  This would also appear to be a binary 
incompatibility and it appears to be a case where installing RPMs based 
only on the LSB version isn't going to work when you go to upgrade. 
Even if you don't use any of the new features in the GTK+ upgrade, you 
are still going to need something new in GLib 2.10.

But it gets worse.  GLibc 2.10.x breaks aRts (reports: "Invalid 
argument") and, it appears some other stuff but this may be related), so 
I find myself with a rather large mess which I think is caused by binary 


More information about the kde-core-devel mailing list