Re: More Pango/GTK+ Build Problems

[Eric Mader <mader jtcsv com>]

At 06:55 PM 8/8/2002, Owen Taylor wrote:

> > In gtk+/configure.in PANGO_PACKAGES is defined once as "pangox
> > pangoxft" and once as "pangoxft pangox" It looks like it needs to
> > always be defined as "pangox pangoxft" in order to get the --cflags in
> > the correct order. Here's what pkg-config says:
> >
> > [emader doramichan gtk+]$ pkg-config --cflags pangoxft pangox
> >    -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> > -I/usr/local/include/pango-1.0 -I/usr/X11R6/include
> > -I/usr/local/include -I/usr/include/freetype2
> > [emader doramichan gtk+]$ pkg-config --cflags pangox pangoxft
> >    -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> > -I/usr/local/include/pango-1.0 -I/usr/local/include
> > -I/usr/include/freetype2 -I/usr/X11R6/include
> > [emader doramichan gtk+]$
> >
> > Notice that in the first one, /usr/X11R6/include is *before*
> > /usr/local/include. This causes pangoxft.h to find the wrong version
> > of Xft.h and complain about a bad version number.
>
> Yeah, unfortunately Xft doesn't install by default in a
> parallel-install friendly way. (Long term, the intent isn't
> to support parallel install)
>
> The two changes that I did in our packaging are:
>
>  Put the headers in /usr/include/Xft/X11/Xft/Xft.h
>  Installed the .so symlink as /usr/lib/libXft2.so so that
>   you link to -lXft2
>
> Then changed xft.pc to match
>
> I suspect if you grab the freetype, fontconfig, and Xft RPMS
> from:
>
>  ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/
>
> and run 'rpm --rebuild' on them, the resulting RPMS should
> work fine on Red Hat 7.2 or 7.2. (They are somewhat old versions,
> idiosyncratically patched, but they definitely work with the
> current Pango. I hope to get them updated to the current release
> candidate soon.)
>
> I'm not sure that even with those changes it will be 100% reliable,
> but it should be better. Moving the Xft1 headers away is
> probably safest.
>
> I've also mad your change to configure.in in HEAD to order the
> first setting of PANGO_PACKAGES to pangoxft / pangox. I'm not
> completely convinced that it should matter there, but it
> shouldn't hurt.

Here's the exact error that I'm getting:
[emader doramichan emader]$ cd gtk+
[emader doramichan gtk+]$ make
make  all-recursive
make[1]: Entering directory `/home/emader/gtk+'
Making all in po
make[2]: Entering directory `/home/emader/gtk+/po'
make[2]: Leaving directory `/home/emader/gtk+/po'
Making all in gdk-pixbuf
make[2]: Entering directory `/home/emader/gtk+/gdk-pixbuf'
Making all in pixops
make[3]: Entering directory `/home/emader/gtk+/gdk-pixbuf/pixops'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/emader/gtk+/gdk-pixbuf/pixops'
make[3]: Entering directory `/home/emader/gtk+/gdk-pixbuf'
make[3]: Leaving directory `/home/emader/gtk+/gdk-pixbuf'
make[2]: Leaving directory `/home/emader/gtk+/gdk-pixbuf'
Making all in gdk
make[2]: Entering directory `/home/emader/gtk+/gdk'
Making all in x11
make[3]: Entering directory `/home/emader/gtk+/gdk/x11'
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-DG_LOG_DOMAIN=\"Gdk\" -DINSIDE_GDK_X11 -I../.. -I../../gdk -I../../gdk 
-DG_ENABLE_DEBUG -pthread -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/pango-1.0 
-I/usr/X11R6/include -I/usr/local/include -I/usr/include/freetype2    -g 
-O2 -g -Wall -c gdkdrawable-x11.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\"Gdk\" -DINSIDE_GDK_X11 
-I../.. -I../../gdk -I../../gdk -DG_ENABLE_DEBUG -pthread 
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
-I/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include 
-I/usr/include/freetype2 -g -O2 -g -Wall -Wp,-MD,.deps/gdkdrawable-x11.pp 
-c gdkdrawable-x11.c  -fPIC -DPIC -o gdkdrawable-x11.o
In file included from gdkdrawable-x11.c:34:
/usr/local/include/pango-1.0/pango/pangoxft.h:37:2: #error "must have Xft 
version 2 or newer"
make[3]: *** [gdkdrawable-x11.lo] Error 1
make[3]: Leaving directory `/home/emader/gtk+/gdk/x11'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/emader/gtk+/gdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/emader/gtk+'
make: *** [all-recursive-am] Error 2
[emader doramichan gtk+]$

Notice that the order of the includes matches what you get from:

pkg-config --cflags pangoxft pangox

Also notice that /usr/X11R6/include is before /usr/local/include. The 
correct version of Xft.h is in /usr/local/lnclude and so won't get seen 
because the one in /usr/X11R6/include gets seen first.

(I built xft with:

   ./configure --prefix=/usr/local

So it writes the header files in /usr/local/include)

Because of this, I'm guessing that the problem has to do with the order of 
the arguments to pkg-config. I'll try that change and report the result back.

> > I've been trying to get two builds working at once, one on RedHat7.2
> > and one on RedHat7.3 (I don't recommend this unless you're a thrill
> > seeker :-)
> >
> > It seems that RH7.3 installs a version of pkg-config. This had two
> > consequences I didn't expect:
> >
> > 1) I had to set PKG_CONFIG_PATH=/usr/local/lib/pkgconfig to see the
> > correct set of .pc files
> >
> > 2) There is a /usr/share/aclocal/pkg.m4 file installed which contains
> > a version of the PKG_CHECK_CONFIG macro - this gets some of the
> > Makefile's and configure files very upset. I had to rename it to
> > pkg.not-m4 to get all the autogen.sh scripts to run without complaining
>
> What most people do is hack 'aclocal' to not exit on duplicate m4
> files. That is, in:
>
>                 warn "aclocal: $file: $.: duplicated macro \`$1'\n";
> #               $exit_status = 1;
>
> Comment out the second line.
>
> You should just be able to use the pkg-config from 7.3 though,
> so I'm not sure why you would have a duplicate pkg.m4.

There's not a duplicate. The 7.3 system started life as a 7.2 system on 
which I hand-installed pkg-config, and there wasn't a pkg.m4 file at all. 
The problem is that now there is, but there's also a copy of the 
PKG_CHECK_PATH macro in on of the aclocal.m4 files, and the duplicate 
*macro* causes some of the scripts to error. Hiding pkg.m4 was my 
quick-and-dirty solution to the problem. I like hacking aclocal better, I 
think.

> > Also, on RH7.3 the pango samples don't compile; they get a lot of
> > error messages having to do with Qt; I assume that the version
> > installed on RH7.3 is too new... Does anyone have a good work-around
> > for this?
>
> I haven't seen a problem... weird. --disable-qt is always an option.

Again, this is a guess, since I don't see this error on the 7.2 system. I 
haven't looked at it in detail yet.

> Regards,
>                                         Owen

Regards,
Eric