Closed
Bug 175523
Opened 22 years ago
Closed 22 years ago
building with --enable-xft not possible (FreeBSD, gcc 3.2.1)
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: mchopra, Assigned: blizzard)
References
Details
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•22 years ago
|
||
Blizzard probably wants this.
Assignee: bryner → blizzard
Component: build-config → Build Config
Product: Phoenix → Browser
Version: unspecified → other
Comment 2•22 years ago
|
||
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....
Comment 3•22 years ago
|
||
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•22 years ago
|
||
I've got Xft2 on this FreeBSD box here. [16:03 munish@opiate ~] xft-config --version 2.0.0
Comment 5•22 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•22 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•22 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
Closed: 22 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 8•22 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•22 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•22 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•22 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•22 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.
Comment 13•22 years ago
|
||
*** Bug 179251 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
*** Bug 183316 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•