Dependency libraries and ABI

[Owen Taylor <otaylor redhat com>]

Havoc pointed this out to me:

Even though we are planning for long term ABI stability in the 2.x series
of GTK+, we have an effective ABI problem because the Xft (and probably
also FreeType) libraries will do major version upgrades before we change
the GTK+ ABI.

That is, if a program is linked to the shared libraries

 libgtk-x11-2.0.so.0
 libXft.so.1

And -lXft changes to libXft.so.2, we can't change GTK+ to depend on the
new libXft because we'll then be linking to both versions of libXft,
and there will be problems with getting symbols from the wrong version
of libXft. (Also, you can't pass a Xft v.1  XftFont to an Xft v.2 library
or vice versa.)

My best idea right now is to:

 - Omit dependency libraries from the pkg-config output lines if we
   think we are on a platform that support shared library dependencies.
   We could autodetect this or, more simply, have a configuration
   option --disable-direct-dependencies (or something.)

   [ This breaks static linking, of course, but not many people want to 
   static link. In the future, we can enhance pkg-config to have some
   special support for static-linking-only dependencies. ]

   This means that libgtk-2.0.so.0 will pull in libXft.so.1, but the
   app won't pull it in explicitely, so as long as the app isn't
   using Xft directly, we can change GTK+ to link against libXft.so.2

 - Say that if you want ABI compatibility, you can't reference symbols
   in libXft.so.1 from your application, and check this in whatever 
   platform ABI xchecking tools are in use.

So, this is something that basically has to be done at the packaging /
platform vendor level.

Unfortunately, the breakage for apps that _do_ use Xft directly will
not be a straightforward missing library, but obscure death from
mixing versions of Xft.

Regards,
                                        Owenp