Ethereal-dev: Re: [ethereal-dev] "autogen" problems in CVS sources

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Mon, 17 Jul 2000 16:36:58 -0700 (PDT)
> 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.