This bug was found on a dual proc DECServer 5305. Regarding the gtk+-2.2.2-r1 build. There is a patch (gtk+-2-xftprefs.patch) for gtk that places an inlude for X11/Xft/Xft.h, normally not a problem. The issue here, is that the configure script does no verification of the existence or version of that file. Nor does it rely on pangoxft. I have been running XFree 3.3.6 due to a problem I'm having with screen corruption with the 4.x series on this alpha machine. Hence, I do not have xft installed, and the compile for gtk fails, as follows: cc: Severe: gtksettings.c, line 46: Cannot find file <X11/Xft/Xft.h> specified in #include directive. (noinclfilef) #include <X11/Xft/Xft.h> -^ make[3]: *** [gtksettings.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2/gtk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2' make: *** [all-recursive-am] Error 2 !!! ERROR: x11-libs/gtk+-2.2.2-r1 failed. !!! Function src_compile, Line 66, Exitcode 2 !!! (no error message) I'm not sure how gtk itself handles the existence of xft. Since there must be a methodology in place for this, it should also be handled in that fashion in the patch. gtk+-2.2.1-r1 does build correctly on this system, but it does not include the patch noted above. Portage 2.0.48-r7 (default-alpha-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20 alpha EV56 GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="alpha crypt cups encode foomaticdb gif gnome jpeg kde libg++ mikmod ncurses nls oss pdflib png qt quicktime sdl spell truetype xml2 xmms xv zlib gnome-libs gdbm berkdb slang readline java guile mysql X gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk motif opengl" COMPILER="gcc3" CHOST="alpha-unknown-linux-gnu" CFLAGS="-mcpu=ev56 -Wa,-mev6 -O3 -pipe -fPIC" CXXFLAGS="-O2 -pipe" ACCEPT_KEYWORDS="alpha ~alpha" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="ccache"
although i agree that this is a problem that should be fixed, the fact is that Gentoo doesn't really support xfree 3. That makes this low priority for us. There's already ifdefs around the patchcode, i suppose those are not completely correct. To my knowledge there is an xft test and the variable set by it should be used. It would be helpful and speed up the fixing of this bug if you could check out what var that is, fix the patch, test and submit it here.
The define from the configure script is simply HAVE_XFT. I have updated the patch from the previous define (GDK_WINDOWING_X11) locally, and tested it. It seems to work on my machine running XFree 3.3.6, correctly catching the fact that I do not have Xft. I also tested this on my athlon machine, however that failed on an #include for gtk/x11/gdkx.h as such: gtksettings.c:27:22: gtk/x11/gdkx.h: No such file or directory gtksettings.c: In function `gtk_settings_class_init': gtksettings.c:383: parse error before ';' token gtksettings.c: In function `gtk_settings_get_for_screen': gtksettings.c:435: warning: implicit declaration of function `GDK_SCREEN_XDISPLAY' gtksettings.c:436: warning: implicit declaration of function `GDK_SCREEN_XNUMBER' gtksettings.c:438: warning: passing arg 1 of `pango_xft_set_default_substitute' makes pointer from integer without a cast gtksettings.c: In function `gtk_settings_notify': gtksettings.c:572: warning: implicit declaration of function `GDK_SCREEN_NUMBER' gtksettings.c:572: warning: passing arg 1 of `pango_xft_substitute_changed' makes pointer from integer without a cast make[3]: *** [gtksettings.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2/gtk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gtk+-2.2.2-r1/work/gtk+-2.2.2' make: *** [all-recursive-am] Error 2 !!! ERROR: x11-libs/gtk+-2.2.2-r1 failed. !!! Function src_compile, Line 66, Exitcode 2 !!! (no error message) If that is a real problem, I can get a patch together to fix it. If not, I'll just fix it on this machine. I do have the patch with the #define's modified, if you would like a copy I can put it in notes here, email it to you, or try to attach it to the bug (had problems with that before). Correct me if I am wrong, but AFAIK the 4.1.x series of XFree does not use Xft either, and that is still in the ebuild tree.
maybe it works to not replace the defines, but add the xft defs to catch both conditions. And yes we have non xft xfree's, but the patch is only in gtk+-2.2.2-r1 and that one depends on xfree-4.3.0-r3 and up for other reasons. preferred way is attaching patches here, if it really doesn't work (seems odd) you can mail me.
Created attachment 16591 [details, diff] Updated ifdef's for HAVE_XFT
Well... it threw an error, but it still put the file up. I mispoke earlier, the patch doesn't change the #defines, but the #ifdef's. Now onto finding this gtk/x11/gdkx.h problem...
any news on this front ?
As far as the bug on my athlon? Not sure, rsynced and emerged again and it went through. As far as the alpha, I believe the patch I put up here does correct the problem.
i don't think this has anything todo with platforms (?) it's about using an old xft-less xfree
As far as I've been able to determine on my handy DEC machine here, the patch that I supplied will correct it. It's an updated gtk+-2-xftprefs.patch. That's where the problem actually lies. There is a HAVE_XFT define set by configure, for some reason the script did not use this as a flag to determine the correct properties to set. It was using GDK_WINDOWING_X11 for some reason. Oh, and sorry about the platform thing, I got out of work a few hours ago... I'm still a bit out of it. I believe you are right in thinking that the problem is not confined to an architecture. At any rate, the patch I supplied is what I used as a replacement for the original patch, using the modified patch, the gtk source compiled without any trouble. Even without the existence of xft.
I just tried with your (Timothy's) patch (c2d3368bbfe3d6b78d335a68ceb148da files/gtk+-2-xftprefs.patch) and emerge still dies with: >>> emerge (1 of 3) x11-libs/gtk+-2.2.4-r1 to / >>> md5 src_uri ;-) gtk+-2.2.4.tar.bz2 >>> Unpacking source... >>> Unpacking gtk+-2.2.4.tar.bz2 to /var/tmp/portage/gtk+-2.2.4-r1/work [...] checking for IceConnectionNumber in -lICE... yes checking for XRenderFindFormat in -lXrender... yes checking for XftFontOpen in -lXft... yes checking X11/Xft/XftFreetype.h usability... no checking X11/Xft/XftFreetype.h presence... no checking for X11/Xft/XftFreetype.h... no configure: error: pangoxft Pango backend found, but Xft not found !!! ERROR: x11-libs/gtk+-2.2.4-r1 failed. !!! Function econf, Line 14, Exitcode 1 !!! econf failed Should I post my config.log? Anything else I can do to help?
@comment #10 : This looks like a different problem and completely unrelated, file a new bug. @reporter : I'm not sure what held this so long (probably the fact that this could never be a problem in the tree), but the patch looks fine and can replace the one currently in portage.
patch should be updated for gtk 2.4 i guess. At this point i'm not sure this is worth pursueing any further (seeing that it fixes a situation that should never occur in Gentoo).
WONTFIX, too much a cornercase & no patch
