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)
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.
Comment 3•22 years ago
|
||
Blizzard, this was the case that we discussed before.
Assignee: seawood → blizzard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•22 years ago
|
||
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?
Comment 5•22 years ago
|
||
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.
Updated•22 years ago
|
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
Updated•22 years ago
|
Blocks: xft_tracking
Assignee | ||
Comment 6•22 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•