building with --enable-xft not possible (FreeBSD, gcc 3.2.1)

RESOLVED INVALID

Status

SeaMonkey
Build Config
RESOLVED INVALID
16 years ago
14 years ago

People

(Reporter: Munish Chopra, Assigned: blizzard)

Tracking

Trunk
x86
FreeBSD

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
FreeBSD 5.0-CURRENT from Oct 15, 2002.
gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)

The error:
In file included from nsGfxFactoryGTK.cpp:65:
nsFontMetricsXft.h:248: syntax error before `*' token
gmake[5]: *** [nsGfxFactoryGTK.o] Error 1

The offending line(s):
    // Xft-related items                                                        
    nsFontXft           *mWesternFont;
    FcPattern           *mPattern;
    PRBool               mMatched;

Line #248 being "FcPattern           *mPattern;".

I'd be glad to test any patches or anything. If I bombed this bug report, sorry,
it's my first one.

Comment 1

16 years ago
Blizzard probably wants this.
Assignee: bryner → blizzard
Component: build-config → Build Config
Product: Phoenix → Browser
Version: unspecified → other
I've seen several people report this on IRC.  Every single one had a horked Xft
install (apparently there is some packagelike thing that does this) which was
pulling in the wrong headers such that "FcPattern" was not defined....
Ho-hum.  Do we build with Xft 1.19?  That's what people seem to have, mostly....

configure doesn't seem to be doing a version check....
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

16 years ago
I've got Xft2 on this FreeBSD box here.

[16:03 munish@opiate ~] xft-config --version
2.0.0

Comment 5

16 years ago
Xft 2.0.0 here too, on a PC running Mandrake 9.
I have installed Xft 2 and fontconfig from fontconfig.org.

--
Problem is very likely that the wrong fontconfig.h file is included by Mozilla's
headers.
Here is the version line of ~/mozilla/Xft/fontconfig/fontconfig/fontconfig.h:
$XFree86: xc/lib/fontconfig/fontconfig/fontconfig.h,v 1.7 2002/03/03 18:39:04
keithp Exp $

Here is the version line of /usr/local/include/fontconfig/fontconfig.h:
$XFree86: xc/lib/fontconfig/fontconfig/fontconfig.h,v 1.28 2002/08/24 20:08:53
keithp Exp $
(Reporter)

Comment 6

16 years ago
If differing versions of fontconfig.h truly are at the root of this, you seem to
be correct.

I have /usr/X11R6/include/fontconfig/fontconfig.h, which corresponds to
fontconfig.h,v 1.28. Checking the mozilla 'port' (that's what we call our 3rd
party app system, for those who don't know), I see fontconfig.h,v 1.7, and
mozilla *is* buildable with Xft. Curiously, I don't have an Xft directory in my
cvs'ed mozilla sources for phoenix...is there a way to especially have it
downloaded by setting something in .mozconfig? I tried setting export
MOZ_INTERNAL_LIBART_LGPL=1 , mk_add_options MOZ_LIBART_INTERNAL_LGPL=1 and
ac_add_options --enable-svg a few days ago to build with svg support, but had no
real luck (I'm not sure whether I was supposed to download something manually?).

I'm not very familiar with the mozilla build process yet (for example,
other-licenses stuff), my apologies if these are trivial issues.
(Assignee)

Comment 7

16 years ago
Make sure that you have version 2.0 of Xft and fontconfig from fontconfig.org
and there are no extra versions of the headers hanging around or Xft won't build.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 8

16 years ago
The real 'fix' was to replace a reference to the Xft.h file, as the correct one
is Xft2.h (for us anyway). For instance, the FreeBSD mozilla/phoenix ports now
use a bit of sed to accomplish this:

sed -i.bak -e 's|X11/Xft/Xft\.h|X11/Xft/Xft2.h|g'
gfx/src/gtk/nsDrawingSurfaceGTK.cpp gfx/src/gtk/nsFontMetricsXft.h

(note -i is FreeBSD-specific, creates a backup of the original file)

After that it builds fine, thanks for the suggestions.
(Assignee)

Comment 9

16 years ago
Are you telling me that FreeBSD uses Xft2.h instead of Xft.h?  They changed the
name of a header file?
(Reporter)

Comment 10

16 years ago
Pretty much, yes. It took a lot of screwing around before I even dreamed of
looking there. Basically it's not FreeBSD's fault, but the port maintainer's. I
believe the reason for this change is to allow multiple version of Xft to
coexist - I can't see any other good reason.
I haven't inquired further about the matter since it seems that the ports people
are content to let sed do the necessary work until XFree86-4.3.0 arrives (which,
from what I hear, will contain Xft?).
(Assignee)

Comment 11

16 years ago
Xft2 contains runtime support for Xft1, I don't know about build-time, though. 
Keith?  Would you expect it to compile properly?

Using Xft2.h is just a terrible idea, though, since it's incompatible with
everyone else who might be building with Xft.

Comment 12

16 years ago
I no longer support building against version 1 of the Xft library.  Applications
are expected to migrate to the current version of the library if they want to
build against a current XFree86 installation.

To force this issue, I purposefully install only the version 2 header files and
link-time library.  The header file retains the same name so that applications
aren't brought forward with the older library interfaces, but are instead
modified to handle the new interfaces.  As promised in the Xft documentation,
Xft2 provides some source-level compatibility with Xft1, enough to make the
porting effort generally easy.

It appears that the FreeBSD XFree86 port maintainer has a bug here.
*** Bug 179251 has been marked as a duplicate of this bug. ***
*** Bug 183316 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.