Bug 97224 - libXft.a the static Xft-1 libary is missing
Summary: libXft.a the static Xft-1 libary is missing
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-11 17:13 UTC by Need Real Name
Modified: 2007-03-27 04:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-11 18:13:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2003-06-11 17:13:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.0.2) Gecko/20030208

Description of problem:
libXft.a the static Xft-1 libary is missing.

The matching cpp-header -file is present under 

The matching dynmic libary is also there

the static libary ist missing in XFree86-devel-4.2.0-72.i386.rpm.
it is also not present in  XFree86-libs-4.2.0-72.i386.rpm that deliver the
dynamic libarys.

(under RedHat 7.x and 9.0 it is part of XFree-devel-4.x.x.i386.rpm) 
suse and debian deliver this libary by default.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.I have the source of some Program's that needs  Xft-1 like imoose and some Qt
using tools.
2.a simple "make all" failes wenn trynig to link libXft.a by -lXft     

Actual Results:  make fail's and exit withs error. It is not possible to build
any Software that need's the static Xft-1 libary.

Expected Results:  if libXft.a ist present, it ist possible to link it

Additional info:

It does not make sense to have Xft.h without libXft.a, it's a bug.

I need imoose for my work, i installed suse 8.1 on my computer in the
University-Bremen, and build imoose on suse with no problems.  
But we prefer Redhat in Bremen in the university.

Comment 1 Mike A. Harris 2003-06-11 18:13:21 UTC
Red Hat Linux 7.3 shipped Xft 1.1.

Red Hat Linux 8.0 shipped with:

- Xft 1.2 for binary runtime compatibility as a shared library *only*,
which Keith packard wrote to replace Xft 1.1 so that both Xft 1 and 2 could
co-reside and both use the same font configuration system (fontconfig), instead
of having 3 different font setups on one OS in order to get all X apps working
properly, which would be insane.  libXft.a is not accidentally missing from
the XFree86 packages, it is intentionally missing, as Red Hat Linux 8.0
only provides runtime compatibility for the legacy version of Xft, and nothing
in the distribution uses it except xterm and xditview, both of which compile
as part of XFree86 building, so the developmental libraries aren't needed
and are not supported for Xft 1.x, and the Xft1 headers are also intentionally
not provided or supported.

- Xft2, as the officially supported Xft, which everything in the distribution
which uses Xft, including KDE, GNOME and all applications (except xterm and
xditview) use.  The static libXft.a which ships with the distro, is the
Xft2 one, and that is part of the Xft-devel package.

Red Hat Linux 9 ships the XFree86 4.3.0, which contains both Xft1 and Xft2
all as part of XFree86, as Keiths updated stuff got merged into 4.3.0.  Xft1
is provided again only for runtime shared library support, and is not a
compile target, and not supported.  The libraries we ship, are the ones
that XFree86 builds by default.

Only Xft2 is supported by Red Hat Linux for developmental and compilation
purposes.  Xft1 is provided only for xterm/xditview, and whatever 3rd party
binary apps happen to work with it, but it is deprecated and not supported.

Developers should consider porting their applications from Xft1 to Xft2, as
the Xft1 interfaces were experimental only, and deprecated when Xft2 came out.

Note You need to log in before you can comment on or make changes to this bug.