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

[Alex Graveley]

Great email Billy!  This is exactly the kind of information I feel we 
need before we can progress.

1) This one seems like a bug in pkg-config, or in individual packages. 
I don't think much can happen on this front without a more rigorous 
pre-release testing process.

2) We do almost exactly the same thing at VMware.  Luckily we are not 
limited to a single physical machine ;-)

3) I've just filed bug #323614.

4) You are screwed (until the LSB waves it's magic stick).  We need to 
get this transition documented and a matrix of distros up someplace.  Do 
you have any of this information gathered already or should I contact 
distros independently?

5) We have this same problem.  I'm not sure what the best solution is.

-Alex


Billy Biggs wrote:
> 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
> 
> _______________________________________________
> Portland mailing list
> Portland at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/portland