Xft source files return compile time error



Build Config
15 years ago
4 years ago


(Reporter: Joshua Kwan, Assigned: blizzard)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

859 bytes, patch
hacker formerly known as seawood@netscape.com
: review+
Details | Diff | Splinter Review


15 years ago
I am building Mozilla from source to a Phoenix distribution (using some stuff in
my .mozconfig):

export MOZ_PHOENIX=1
mk_add_options MOZ_PHOENIX=1
ac_add_options --enable-crypto
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-mailnews
ac_add_options --disable-composer
ac_add_options --enable-strip
ac_add_options --enable-strip-libs
ac_add_options --enable-optimize="-O3 -march=i686"
ac_add_options --enable-xft
ac_add_options --with-glib-prefix=/usr

Configuring is all fine and dandy - there are no errors whatsoever.
However after running make -f client.mk build:

In file included from nsGfxFactoryGTK.cpp:65:
nsFontMetricsXft.h:248: syntax error before `*'
nsGfxFactoryGTK.cpp: In function `nsresult
nsScriptableRegionConstructor(nsISupports *, const nsIID &, void **)':
nsGfxFactoryGTK.cpp:171: warning: `class nsIScriptableRegion * inst' might be
used uninitialized in this function
make[5]: *** [nsGfxFactoryGTK.o] Error 1

Since I had grabbed a nightly bz2ball from the website, i ran a cvs update to
see whether the problem had been rectified recently. These files ended up
updating, so i made clean and tried again. Same problem.

Mou... so close, yet so far to an xft enabled phoenix! (yes you should release
official binaries for phoenix+xft :))

Thanks for all the hard work you guys, though.
you need xft 2.0 to build Mozilla with XFT support.  We should be testing for
this in configure...
Assignee: seawood → blizzard
Whiteboard: DUPEME

Comment 2

15 years ago
I had the same problem, this simple patch might fix it

--- nsFontMetricsXft.h.old      Mon Nov  4 10:05:21 2002
+++ nsFontMetricsXft.h  Mon Nov  4 10:05:22 2002
@@ -49,6 +49,7 @@
 #include <X11/Xft/Xft.h>
 class nsFontXft;
+class FcPattern;
 class nsFontMetricsXft : public nsIFontMetricsGTK


15 years ago
Blocks: 172768
Ever confirmed: true

Comment 3

15 years ago
I'm using Xft2 and am having this problem.  It *appears* as if the problem is this:

there is an Xft/Xft.h in /usr/X11R6/include/X11 and this one is being picked up
instead of /usr/include/Xft2/X11/Xft/Xft.h

reordering the compile to put -I/usr/X11R6/include at the end works.

My world in which this is happening is:

RedHat 7.3 w/ Ximian stuff:
XFree86-devel-4.2.0-8   (has the rogue Xft.h)

I hope that helps.

Comment 4

15 years ago
OK, so it's a problem with the include files on your system then.
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 5

15 years ago
v invalid.
*** Bug 183316 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
*** Bug 183341 has been marked as a duplicate of this bug. ***

Comment 8

15 years ago
*** Bug 183337 has been marked as a duplicate of this bug. ***

Comment 9

15 years ago
*** Bug 183337 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
i believe comment #4
"OK, so it's a problem with the include files on your system then."
is an incorrect diagnosis... it is the mozilla config scripts which are to lame
as they should always place the fontconfig/Xft2 includes before the X11R6 ones
(if they are different locations) a temporary workaround for me was to force the
Xft2 includes at the front of the gcc queue with

make CXX="$CXX -I/opt/gnome/include"

since /opt/gnome is the prefix of my Xft2 and fontconfig installs.

but i definitely believe this is not a problem with peoples 'include' setups,  s
there is no such thing as an "include setup"... mozilla does it all with  configure.

this is far from a "major bug".
a quick hack in gfx/src/gtk/Makefile.in would be to do something like


to ensure the XFT_CFLAGS are the first to be processed. i suppose...


Comment 11

15 years ago
So you still have the old Xft.h hanging around?  I still don't know what to do
about that.  I haven't been able to control the order of the includes properly.

Chris, any ideas about that?  I need to make sure that the includes for
MOZ_XFT_CFLAGS come before the X11R6 includes.
Use LOCAL_INCLUDES instead of appending those variables to CFLAGS & CXXFLAGS.

Comment 13

15 years ago
Xft.h from fontconfig version 2.1 is not called Xft2.h as far as I can tell. Is
moz 1.2.1 supposed to built cleanly from
http://fontconfig.org/release/fcpackage.2_1.tar.gz or verison 2.0?

I tried comment 2 but that didn't help. I'll try some of the configure ideas

Comment 14

15 years ago
Resolution: INVALID → ---

Comment 15

15 years ago
*** Bug 184396 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
I tried using LOCAL_INCLUDES instead of appending it to the CFLAGS and it didn't
make a difference.  The Xft2 include came well after the X11R6 include.

Comment 17

15 years ago
as a hack, try appending MOZ_XFT_CFLAGS to CXX in this directory only.
Something's wrong there if X11R6 is showing up before LOCAL_INCLUDES.  What does
your compile line look like?  In widget/src/gtk, LOCAL_INCLUDES are showing up
well before the X11R6 includes.

Comment 19

15 years ago
Created attachment 108789 [details] [diff] [review]

Comment 20

15 years ago
Created attachment 108791 [details] [diff] [review]

oops, use tabs not spaces
Attachment #108789 - Attachment is obsolete: true

Comment 21

15 years ago
I didn't realize that LOCAL_INCLUDES was being squashed later in the makefile. 
This moves it before the include for X11R6.

Comment 22

15 years ago
Comment on attachment 108791 [details] [diff] [review]

requesting review from cls
Attachment #108791 - Flags: review?(cls)
Attachment #108791 - Flags: review?(cls) → review+

Comment 23

15 years ago
Comment on attachment 108791 [details] [diff] [review]

a=asa for checkin to 1.3a
Attachment #108791 - Flags: approval1.3a+

Comment 24

15 years ago
Checked in.
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 25

15 years ago
I just grabbed a fresh cvs and while the build was fine, I get this error:

./mozilla-bin: relocation error:
/home/manuel/mozilla/dist/bin/components/libgfx_gtk.so: undefined symbol:

Comment 26

15 years ago
Geez, sounds like we're linking against the old Xft library.

Comment 27

15 years ago
Well, i still don't follow how people have their libs called xft2, or something
with a 2 in the lib's name lib.so.2, whatever, whereas my install from the
latest fcpackage simply calls then xft, and I put them in /usr/local

Product: Browser → Seamonkey


4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.