Closed Bug 131466 Opened 22 years ago Closed 22 years ago

Build problems with XFT enabled on Debian/Testing/Unstable Linux -- MOZ_XFT_CFLAGS improperly set

Categories

(SeaMonkey :: Build Config, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: trelane, Assigned: blizzard)

References

Details

When compiling with XFT enabled, I get the following error:
make[3]: Entering direc
tory `/usr/local/src/mozilla/other-licenses/Xft/Xrender'
Composite.c
gcc -o Composite.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\" -DOJI   -I../../.
./dist/include/Xrender/X11/extensions -I../../../dist/include -I/usr/local/src/b
uilding/moz/mozilla/dist/include/nspr         -fPIC -I/X11/extensions -I./extens
ions   -include ../../../config-defs.h -DMOZILLA_CLIENT -Wp,-MD,.deps/Composite.
pp Composite.c
In file included from Composite.c:26:
Xrenderint.h:33: Xext.h: No such file or directory
In file included from Composite.c:26:
Xrenderint.h:36: renderproto.h: No such file or directory
make[3]: *** [Composite.o] Error 1
make[3]: Leaving directory `/usr/local/src/mozilla/other-licenses/Xft/Xrender'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/usr/local/src/mozilla/other-licenses/Xft'
make[1]: *** [tier_9] Error 2
make[1]: Leaving directory `/usr/local/src/mozilla'
make: *** [default] Error 2

However, 
$ locate renderproto.h
/cygdrive/j/oo_641c_src/external/x11/extensions/renderproto.h
/cygdrive/j/oo_641c_src/solver/641/unxlngi3.pro/inc/x11/extensions/renderproto.h
/usr/X11R6/include/X11/extensions/renderproto.h
$

Also,
mozilla/config:5$ grep '/X11' *
grep: CVS: Is a directory
autoconf.mk:XLDFLAGS    =  -L/usr/X11R6/lib
autoconf.mk:MOZ_GTK_CFLAGS              = -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
autoconf.mk:MOZ_GTK_LDFLAGS             = -L/usr/lib -L/usr/X11R6/lib -lgtk
-lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
autoconf.mk:MOZ_XPRINT_LDFLAGS  =  -L/usr/X11R6/lib -lXp -lXext -lX11
autoconf.mk:MOZ_XFT_CFLAGS              =  -I/X11/extensions
autoconf.mk:MOZ_XFT_LIBS                =  -L/usr/X11R6/lib
grep: mac: Is a directory
grep: mkdepend: Is a directory
grep: os2: Is a directory


It looks like MOZ_XFT_CFLAGS is being improperly set.  It *should* be
-I/usr/X11R6/include/X11/extensions instead of -I/X11/extensions.

I'll poke around a little bit and make a patch.
OK.  Found where it's coming from, to a degree.

Apparently, I'm having some problems configuring X on my system, and x_includes
is getting unset:

$ diff -u configure+ configure
--- configure+  Sat Mar 16 15:30:23 2002
+++ configure   Sat Mar 16 15:31:09 2002
@@ -3397,7 +3397,7 @@
 if test -z "$ac_err"; then
   rm -rf conftest*
   # We can compile using X headers with no special include directory.
-ac_x_includes=
+ac_x_includes=/usr/X11R6/include
 else
   echo "$ac_err" >&5
   echo "configure: failed program was:" >&5


Still digging, but I think this will make it happy on my system for now.
OK.  Got it, I think, sans patch yet, but I gotta go get my cap & gown for
graduation.

Anyway, the MOZ_XFT_CFLAGS setting stuff is assuming that $x_includes is going
to be set.  However, if including -I/usr/X11R6/include in the *CFLAGS is
unnecessary, then $ac_x_includes (and, throught it, $x_includes) gets set to ""
(or sort of unset).  This is a problem, since the setting of MOZ_XFT_CFLAGS
blindly assumes $x_includes is set, and to a non-empty string.  The problem
would also occur for anything that needs the X11 extensions stuff.

The Proper Behaviour in my estimation, then, is to have a separate
x_extensions_include, which is set to the proper value, cheating through
ac_x_includes if set, which can then be used for MOZ_XFT_CFLAGS.

I'd make the patch, but it'll require a little work, and I have to get my
graduation stuff.
Blizzard, this was the case that we discussed before.
Assignee: seawood → blizzard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah, I'm not sure what do do about this.  Chris, what do you think I should be
doing here so I get the ext directory?
Well, the problem occurs when the X11 headers are found in a place that the
compiler searches by default, right?  This is the condition that causes
x_includes to be unset.  We should check to see if x_includes is empty and
attempt to set the XFT include path used by testing for the X11 include dir in
/usr/include.  If that fails, then we'll want to error out saying that the
x_include dir cannot be found and the developer must use --x-includes.
Summary: Build probblems with XFT enabled on Debian/Testing/Unstable Linux -- MOZ_XFT_CFLAGS improperly set → Build problems with XFT enabled on Debian/Testing/Unstable Linux -- MOZ_XFT_CFLAGS improperly set
Blocks: xft_tracking
We aren't building with other-licenses at all anymore.  All of the Xft libs and
build requirements are external to Mozilla.  This means that if you want to use
it, you should be using pkgconfig and xft.

I'm going to mark this WONTFIX.  Please re-open if you bump into problems with
Xft and pkgconfig.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
v wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.