Re: More Pango/GTK+ Build Problems

[Owen Taylor <otaylor redhat com>]

Eric Mader <mader jtcsv com> writes:

> Hello,
> 
> Whew! I've had a tough day fighting w/ the Pango build system... I
> still can't get everything to build, but here's what I've learned so
> far:

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

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

Regards,
                                        Owen