Closed Bug 131466 Opened 23 years ago Closed 23 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: 23 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.