On Thu, 10 Oct 2002, Alexander Volovics wrote: >Date: Thu, 10 Oct 2002 00:35:12 +0200 >From: Alexander Volovics <awol@home.nl> >To: psyche-list@redhat.com >Content-Type: text/plain; charset=iso-8859-15 >List-Id: Discussion of Red Hat Linux 8.0 (Psyche) <psyche-list.redhat.com> >Subject: Xft problems with RH-8.0 > >When trying to compile an app (openbox) under RH-8.0 a number of >complications are encountered. > >1) the library libXft.so.2.0 is no longer to be found in > /usr/X11R6/lib (as in RH-7.3) but in /usr/lib No, it never was. libXft.so.2.0 _never_ existed in RHL 7.3 at all ever. Xft2 is new to Red Hat Linux 8.0. Xft2 is in the Xft package in RHL 8.0, because it is a separate library, which is not part of XFree86 4.2.0. The Xft library included with Red Hat Linux 7.3 is Xft 1.1, which is part of XFree86 4.2.0. > (However in /usr/X11R6/lib XFree86-libs-4.2.0-72 installs libXft.so.1.2, > presumably for compatibility reasons for apps compiled under RH-7.3) Xft1 (1.1), included with XFree86 stock sources uses XftConfig. Keith Packard took the Xft1 library, enhanced it to use fontconfig instead of XftConfig, removed the XftConfig baggage, and released it as Xft 1.2 - a drop in replacement for Xft 1.x for XFree86 4.2.0. So, what you get in Red Hat Linux 8.0, is the Xft 1.1 library is gone, now replaced with Keith Packard's official Xft 1.2 library which uses fontconfig. This allows Xft to use one configuration file - /etc/fonts/fonts.conf, and /etc/X11/XftConfig is now obsolete, and gone. Xft2 is a separate RPM (Xft) because it was much easier to have it a separate RPM package to update it quickly and easily without updating XFree86 packages every snapshot, as it was in development during Red Hat Linux development. Having it separate made it ultra simple to update, and makes no difference to the end user. >2) the header file Xft.h is no longer to be found in > /usr/X11R6/include/X11/Xft but in /usr/include/Xft2/X11/Xft Correct. Xft1 development is intentionally not supported, as Xft1 is considered legacy now. Qt is the main thing that used Xft1, very few other things ever used it, and Qt now uses Xft2. Supporting Xft1 for development when so few apps use it, is a waste of time, and only holds back the widespread adoption of Xft2. Xft2 is a significant improvement over Xft1, so the hope is that any interesting applications will be ported to Xft2 properly by their authors. Existing apps using Xft1 should run ok in 8.0 since the fontconfigized Xft1 makes configuration centralized, while allowing precompiled Xft1 apps to continue to work. 1 such app is xterm. 8.0 is a major new release, so ditching legacy stuff, especially which not a lot of things use anyway is a good time to do it. This will again as I said, put a fire under everyone out there to port there Xft1 stuff to Xft2. >3) to make matters worse when you do find your way to /usr/lib and > /usr/include/Xft2/X11/Xft by using LDFLAGS, CPPFLAGS and softlinks > during ./configure you encounter a long list of undefined references, > for example to: FcPatternAddInteger, FcPatternAddBool, etc. Not using xft-config I guess. Probably would be a good idea to use xft-config. [root@devel root]# xft-config --libs -lXft2 -lfreetype -lfontconfig -L/usr/X11R6/lib -lXrender [root@devel root]# xft-config --cflags -I/usr/include/Xft2 -I/usr/include/freetype2 -I/usr/include -I/usr/X11R6/include >4) Snooping around you discover another header file in > /usr/include/Xft2/X11/Xft, namely XftCompat.h. > This file seems to contain the translations from the newer Xft.h > where these things are called for example: XftPatternAddInteger, > XftPatternAddBool, etc. > (but not all the undefined references seem to have translations) > > It is completely unclear how you can make these translations work > and there is no documentation at all. (how do you use XftCompat.h) Just a case of a developer not properly using the tools provided with the operating system. [root@devel root]# rpm -qf $(which xft-config) Xft-devel-2.0-1 ;o) >As a non programmer who has only a very vague idea of what is going on >here and what might be needed I find this very frustrating. Correct, end users shouldn't have to worry about these sort of things. I recommend reporting a bug to the upstream project maintainers of the package which is not using xft-config to autodiscover the proper compiler and linker commandline arguments et al. >Can somebody from RH give some explantion of how this can be solved. >(Or some experienced programmer willing to take the time to instruct me). Hopefully the above information is helpful. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc.
