[Portland] Project Portland, RuDI and the Generic desktop adapter

[Billy Biggs]

nf2 (nf2 at scheinwelt.at):

> As a Java developer i'm using Eclipse quite a lot and ldd reports that
> it dynamically links 32 libraries, including gtk+, glib etc. And it's
> a quite old Eclipse from March 2004. So where is the problem? This ABI
> debate is still a bit mystic to me...

  In reality, the ABI problem isn't as bad as you might think, and the
solutions are all pretty clear.  GTK+ and glib are fully binary
compatible back to 2.0.x and no distribution breaks this.  We also use
gnome-vfs which has been stable, and Mozilla has never broken us either.
We use dlopen() and dlsym() for any functions which are only available
in newer versions of GTK+ or GNOME-VFS, and use the GTK_VERSION macros
to tell if they are available or not.

  So, where are the "ABI" problems?  I'd love to hear from other ISVs,
but here are the ones I can think of off the top of my head:

  1. Libraries going missing.  We used to trust pkg-config, but
     unfortunately it adds -lfoo for all foo, even if you don't use
     anything from foo.  This caused us to have binaries linked to
     liblinc and libpango-xft which weren't always available, even
     though we never used those.

  2. Building against newer libc versions brings in new symbols.  During
     development we often get burned when someone compiles a library on
     their desktop and accidentally checks it into CVS.   There are no
     good "best practice" documents on what apps should be building
     compatible binaries against.  We have some RH9 machine we use for
     builds and hope that it's OK.

  3. Some libraries, such as libgnome-vfs, don't announce their version
     with version macros.  This makes it more difficult to work around
     bugs or know if features are available.

  4. We're currently dealing with mozilla compiled with libstdc++.so.5
     vs libstdc++.so.6.  It seems to work OK if our library is with gcc3
     and mozilla is with gcc4, but who knows??  Already distros are
     stopping to ship the old libstdc++.so.5 library, or move it into
     some compatibility package that nobody has installed.

  5. Sometimes distros backport fixes, and this breaks our ability to
     use the GTK_VERSION macros to work around issues in any sane way.

  Most of these aren't really ABI problems though.  I think most people
think of the advertised-as-unstable libraries for those.  See much of
the GNOME stack, I guess, and probably freetype.

  -Billy