> Since I do not like to pollute a CVS tree with non-CVS-ed files,
> I clone the tree before running (see the attached :mksrc):
>
> [[by the way, same problems without the tree-cloning step]]
...so the attached ":mksrc" may not actually be relevant to the problem.
> $ :mksrc
> Using `AC_PROG_RANLIB' is rendered obsolete by `AM_PROG_LIBTOOL'
> You should add the contents of `/usr/local/share/aclocal/libtool.m4' to
> `aclocal.m4'.
> Running ./configure with no arguments. If you wish to pass any,
> please specify them on the ./autogen.sh command line.
> processing .
> aclocal: configure.in: 120: macro `AM_PATH_GLIB' not found in library
On what OS are you running this?
Did autoconf and automake come with the OS (and are thus presumably
installed somewhere other than "/usr/local"), or were they installed
under "/usr/local"?
autoconf/automake have an extremely irritating characteristic - they
search *only* in the subtree in which they're installed, so that, for
example, versions that come with the OS and that live in "/usr/bin"
won't look under "/usr/local" for macros.
If you have an OS that comes with them (e.g., many Linux distributions),
but installed GTK+ from source in "/usr/local", autoconf and automake
may not find GTK+'s autoconf/automake macros, such as:
> aclocal: configure.in: 126: macro `AM_PATH_GTK' not found in library
...AM_PATH_GTK.
If that's the case, you may have to copy stuff from
"/usr/local/share/aclocal" to "/usr/share/aclocal".
If autoconf and automake were installed in "/usr/local/bin", but GTK+,
say, was installed with the OS, you may have to copy stuff in the other
direction.