Closed Bug 178128 Opened 22 years ago Closed 22 years ago

Xft source files return compile time error

Categories

(SeaMonkey :: Build Config, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joshk, Assigned: blizzard)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
-Josh
you need xft 2.0 to build Mozilla with XFT support.  We should be testing for
this in configure...
Assignee: seawood → blizzard
Whiteboard: DUPEME
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
 {
Blocks: xft_tracking
Status: UNCONFIRMED → NEW
Ever confirmed: true
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)
fontconfig-1.0.1-0.ximian.1
fontconfig-devel-1.0.1-0.ximian.1
Xft-2.0.0-0.ximian.1
Xft-devel-2.0.0-0.ximian.1

I hope that helps.
OK, so it's a problem with the include files on your system then.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
v invalid.
Status: RESOLVED → VERIFIED
*** Bug 183316 has been marked as a duplicate of this bug. ***
*** Bug 183341 has been marked as a duplicate of this bug. ***
*** Bug 183337 has been marked as a duplicate of this bug. ***
*** Bug 183337 has been marked as a duplicate of this bug. ***
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

CXX += $(MOZ_XFT_CFLAGS)

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

cheers,
Sam
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.

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
instead.
Reopening.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
*** Bug 184396 has been marked as a duplicate of this bug. ***
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.
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.
Attached patch patch (obsolete) — Splinter Review
Attached patch patchSplinter Review
oops, use tabs not spaces
Attachment #108789 - Attachment is obsolete: true
I didn't realize that LOCAL_INCLUDES was being squashed later in the makefile. 
This moves it before the include for X11R6.
Comment on attachment 108791 [details] [diff] [review]
patch

requesting review from cls
Attachment #108791 - Flags: review?(cls)
Attachment #108791 - Flags: review?(cls) → review+
Comment on attachment 108791 [details] [diff] [review]
patch

a=asa for checkin to 1.3a
Attachment #108791 - Flags: approval1.3a+
Checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
I just grabbed a fresh cvs and while the build was fine, I get this error:

~/mozilla/dist/bin-->./mozilla
./mozilla-bin: relocation error:
/home/manuel/mozilla/dist/bin/components/libgfx_gtk.so: undefined symbol:
XftLockFace
~/mozilla/dist/bin-->
Geez, sounds like we're linking against the old Xft library.
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

ml
Product: Browser → Seamonkey
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: