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: *** [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.
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
I've got Xft2 on this FreeBSD box here. [16:03 munish@opiate ~] xft-config --version 2.0.0
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 $
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.
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
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.
Are you telling me that FreeBSD uses Xft2.h instead of Xft.h? They changed the name of a header file?
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?).
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.
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. ***
You need to log in before you can comment on or make changes to this bug.