Re: More Pango/GTK+ Build Problems

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

> In gtk+/ 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/ so that
  you link to -lXft2

Then changed xft.pc to match

I suspect if you grab the freetype, fontconfig, and Xft RPMS

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 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 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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]