GNOME ABI is always backwards-compatible, except for when it’s not

So I'm rather surprised by GNOME's response to a recent bug on symbol visibility on Mac OS X. One of the things GNOME has done very well in the past is to always preserve backwards-compatibility, and they've generally stuck to it (and when they haven't, it's been an accident, and has been remedied).

But given the comments on the bug, apparently ELF linking with indirect symbols is now the only officially supported way to compile GNOME libraries, and breaking ABI compatibility is OK as long as it doesn't break any important platforms. (ahem)

I'm in favor of refactoring code to the proper places as much as the next guy, but this is breaking ABI, and should wait for gnome-vfs3. That's the way it works, you're making a compact with the user that as long as this major number doesn't change, your old binaries should still work. It's a shame that they'll break that covenant for the purposes of the convenience of framework developers. It's not like there aren't ways to consolidate the code that doesn't break binary-compatibility.

And here I was going to help Daniel Macks work on getting GNOME modernized in Fink (using my experimental modular x.org Fink packages, and GNOME 2.15/2.16), but suddenly I've got a bad taste in my mouth.

Share on Facebook

1 comment to GNOME ABI is always backwards-compatible, except for when it’s not

  • anne

    “here I was going to help Daniel Macks work on getting GNOME modernized in Fink”
    I hope you will. I haven’t found any way to successfully install gnome on my OSX. I had trouble way down with gawk (I found the patch but gettext still gives me the pieces of cake error message)… and from what I read garnome does not install on mac OS X.
    so I was interested to find your post indicating that someone is working on an installation for Mac OS X, which with some luck will work.