Red Hat Bugzilla – Bug 178443
Need libXft.so.1 compat packages since libXft.so.2 is ABI incompatible with libXft.so.1
Last modified: 2007-11-30 17:11:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 Fedora/1.5-0.fc4 Firefox/1.5
Description of problem:
We have several programs that require libXft.so.1, that would otherwise work on FC5. libXft.so.2 appears to be ABI incompatible with libXft.so.1. (For example, if I add a symbolic link from /usr/lib/libXft.so.2 to /usr/lib/libXft.so.1, it fails with:
some_program: symbol lookup
error: some_program: undefined symbol:
Possible to get compatibility libraries for libXft.so.1?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Find a program that requires libXft.so.1, install it
2. Run it
3. fails with errors above
Actual Results: Program errors out.
Expected Results: Program works. :-) Programs built for xorg-X11 on FC4 won't work. A colleage noted that Ubuntu has packages called libxft1 and libxft2.
A major .so version bump in any library, is an intentional incompatible ABI
revamp by definition. libXft2 has been present in the OS since Red Hat Linux 8,
or perhaps even 7.3. Xft1 was deprecated a very long time ago now. Xft2 has
been present for at least 6-7 OS releases, not counting FC5 development, so
libXft1 is very much antiquated.
X11R7 has officially removed this library now from the X Window System, having
fully obsoleted it now. Fedora Core 5 contains no dependencies on libXft1, and
I believe that Fedora Extras contains no deps on Xft1, however that has not yet
My initial thought was that libXft1 should just vanish completely now, and
any software that is still using it, should get updated to use libXft2. I
still feel that way personally, and it seems that most software out there
has already made this transition a long time ago now.
Nonetheless, I discussed this with a number of other developers to get
other opinions. So far, everyone seems to agree that if libXft1 packages
are provided at all, that they should be moved to Fedora Extras instead
I've thought about it, and I think this is a reasonable compromise, so long
as there is someone in the Fedora community willing to volunteer to maintain
the libXft1 package in Fedora Extras. That keeps core that much cleaner
from archaic stuff that has few things needing it, but still provides users
who are running older software that has not yet been updated to use Xft2
the ability to maintain compatibility with the legacy library if desired.
To facilitate this, I'd be happy to whip up an initial src.rpm of libXft1
if someone in the Fedora Community volunteers to maintain the new package
in Fedora Extras. If anyone is interested, please email me or ping me in
#fedora-x on freenode and we'll discuss the finer details, etc..
Thanks for the detailed response, Mike. Sorry, I didn't realize that
libXft.so.1 was so deprecated. We do plan to rebuild our tools against the new
xorg/libXft.so.2, but was suggested to me to open this anyway. Not sure I'd be
the right person to maintain this package for extras (though I wish I were) for
a number of reasons -- not the least of which is my lack of package-building
experience; although it sounds like that part of your response was directed more
at the general community.
Am I reading that correctly? It sounds like your compromise is very reasonable,
and I'd be happy to help in any way that I can.
(In reply to comment #2)
> Thanks for the detailed response, Mike. Sorry, I didn't realize that
> libXft.so.1 was so deprecated.
Yep, it was the first incarnation of Xft which wasn't widely used. It was
more of a proof of concept at the time, supplanted by Xft2 in the next
X release after it. Xft1 uses XftConfig file, which is not used by Xft2
anymore, having been replaced with fontconfig.
> We do plan to rebuild our tools against the new
> xorg/libXft.so.2, but was suggested to me to open this anyway. Not sure I'd be
> the right person to maintain this package for extras (though I wish I were) for
> a number of reasons -- not the least of which is my lack of package-building
> experience; although it sounds like that part of your response was directed more
> at the general community.
Right, that was intended to a more general audience.
> Am I reading that correctly? It sounds like your compromise is very reasonable,
> and I'd be happy to help in any way that I can.
I'll create a libXft1 package at some point, and make it available on my
personal ftp space, and announce it on the development lists to see if
anyone wants to volunteer to maintain the package in Fedora Extras.
Note however that this is rather low priority currently, as there is a
lot of Fedora Core 5 work to focus on currently. It will probably happen
sometime closer to the FC5 final release, or thereabouts. I'm leaving the
bug open for now as a reminder to myself though, and putting it on the FC5
tracker as well, as an additional reminder.
After searching through freedesktop.org wiki for 15 minutes, I was unable
to find any "official" or "canonical" pointers of where to get the officially
released Xft1 library tarball source from.
I'm still willing to build an initial src.rpm if someone else does the legwork
to find where the actual upstream "official" source tarballs exist.
All I could find was this: http://xorg.freedesktop.org/releases/.
This seemed to have links to older releases as well:
Yeah, that's all I could find too, and it is all X11R7.0 material, nothing
older than that. As a last ditch attempt, I just pinged keithp to find out
where the canonical libXft1 source tarballs are kept.
<keithp> I can't find them either
<keithp> If you do manage to dig one up, we should post it somewhere
<keithp> oh, the only tarball you'd find is a complete 4.3 release
<keithp> Xft1 wasn't released separately
<keithp> and, wasn't made separately buildable either, iirc
<keithp> imake is like that...
So it looks like applications that rely on libXft1 are in fact dependent on
X11R6, and will no longer work with X11R7.0, at least unless someone wants
to become the official upstream maintainer of a modular libXft1 and roll
a modular release of it. ;o)
That's more effort than I'm willing to volunteer however. ;o)