Re: Dependency libraries and ABI

[Havoc Pennington <hp redhat com>]

Keith Packard <keithp keithp com> writes:
> Around 14 o'clock on Feb 27, Havoc Pennington wrote:
> 
> > This situation really sucks... what does Qt do about this? dlopen?
> 
> Qt hasn't faced Xft version 2 yet.  I have patches ready for them, but 
> they haven't merged.  Qt should have no problem with this; they support 
> printing with their API and apps don't generally go around the toolkit to 
> get at the underlying Xft library.

GTK apps don't normally do this either. The problem is just what's on
the link line. If you do -lXft when building your app, you will end up
with a hard dependency on libXft.so.1 and won't be able to use
libXft.so.2 without recompiling the application. If we later changed
GTK+ to pull in libXft.so.2, everything would blow up.

Looking at a random KDE build log from Red Hat's build system, it
doesn't look like they link to Xft explicitly, here are the flags:

 -lfl -lkfile -lkhtml -lkdeui -lkdecore -lqt -lpng -lz -lm -ljpeg
-lXext -lX11 -lresolv -lS M -lICE -lkfile -lkhtml -lkdeui -lkdecore
-lqt -lpng -lz -lm -ljpeg -lXext -lX11 -lresolv -lSM -lICE -lresolv

If I "objdump -p /usr/bin/kwrite" then kwrite does not have a NEEDED
entry for Xft, though it does for all that other stuff mentioned
above, so they are essentially using Owen's solution. Qt 3 itself does
have a NEEDED entry to pull in Xft but the apps don't.

I guess that means if we go with Owen's plan we are at least being
consistent with existing practice.

I think we'll need a pkg-config release that supports this though,
and will need to require it for GTK 2.

> The patches needed to move Gtk+ 2.0 to Xft2 are minor; Xft2 is largely 
> source compatible with Xft1, many of the changes are designed to simply 
> take advantage of new features of Xft2 that improve performance or 
> functionality.  The largest change eliminates miniXft as Xft2 uses 
> Fontconfig instead of an internal font configuration mechanism.

That's reassuring; there are some noises about another GTK release in
a very short timeframe to make multihead support available, so maybe
we could pack this change into that release. 

> Note that Xft1 will be getting ported to Fontconfig in the near term for
> release with XFree86 4.3 -- the alternative leaves yet another incompatible
> font configuration system for another year.

That shouldn't cause problems, since Xft will pull in fontconfig via
its NEEDED entry.

I guess we are basically requiring that target platforms support
shared library dependencies. ;-)

Havoc