7:23 a.m.
Hi Eric,
Just ran ./autogen.sh on an OSX box with only the system provided
autotools installed, and got this:
************************************************************************************
Copying file po/remove-potcdate.sin
./bootstrap: patching m4/gettext.m4 to remove need for intl/* ...
./bootstrap: glibtoolize -c -f ...
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
glibtoolize: copying file `build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
./bootstrap: aclocal -I gnulib/m4 --force -I m4 ...
configure.ac:13: warning: macro `AM_SILENT_RULES' not found in library
./bootstrap: autoconf --force ...
configure.ac:60: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:512: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:627: error: possibly undefined macro: PKG_CHECK_MODULES
Failed to bootstrap, please investigate.
$
************************************************************************************
This system is using the "MacPorts" packaging system instead of Homebrew.
The problem was easy enough to resolve by installing the newer autoconf
and automake MacPorts provides.
But, I'm concerned about the less-than-helpful error message given here.
Isn't the bootstrap supposed to detect the required versions of things (as specified
in the .conf file), and inform us clearly if they're not found?
Regards and best wishes,
Justin Clift
7:35 a.m.
2010/11/29 Justin Clift <jclift(a)redhat.com>:
Hi Eric,
Just ran ./autogen.sh on an OSX box with only the system provided
autotools installed, and got this:
************************************************************************************
Copying file po/remove-potcdate.sin
./bootstrap: patching m4/gettext.m4 to remove need for intl/* ...
./bootstrap: glibtoolize -c -f ...
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
glibtoolize: copying file `build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
./bootstrap: aclocal -I gnulib/m4 --force -I m4 ...
configure.ac:13: warning: macro `AM_SILENT_RULES' not found in library
./bootstrap: autoconf --force ...
configure.ac:60: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:512: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:627: error: possibly undefined macro: PKG_CHECK_MODULES
Failed to bootstrap, please investigate.
$
************************************************************************************
This system is using the "MacPorts" packaging system instead of Homebrew.
The problem was easy enough to resolve by installing the newer autoconf
and automake MacPorts provides.
But, I'm concerned about the less-than-helpful error message given here.
Isn't the bootstrap supposed to detect the required versions of things (as specified
in the .conf file), and inform us clearly if they're not found?
Regards and best wishes,
Justin Clift
Looks like the system is missing pkg-config, or at least has the .m4
file is in an unexpected place so that autoconf can't find it.
bootstrap checks for pkg-config, so the binary is probably there, but
that doesn't mean that autoconf can find the corresponding .m4 file,
if it's there at all.
Matthias
7:42 a.m.
On 30/11/2010, at 12:35 AM, Matthias Bolte wrote:
Looks like the system is missing pkg-config, or at least has the .m4
file is in an unexpected place so that autoconf can't find it.
bootstrap checks for pkg-config, so the binary is probably there, but
that doesn't mean that autoconf can find the corresponding .m4 file,
if it's there at all.
Interesting. When installing autoconf, MacPorts also installs a newer m4
than the system provided one too.
I wonder if there's a better way to cope with this m4 related failure scenario,
than the text presently being given?
8:26 a.m.
Justin Clift wrote:
On 30/11/2010, at 12:35 AM, Matthias Bolte wrote:
> Looks like the system is missing pkg-config, or at least has the .m4
> file is in an unexpected place so that autoconf can't find it.
>
> bootstrap checks for pkg-config, so the binary is probably there, but
> that doesn't mean that autoconf can find the corresponding .m4 file,
> if it's there at all.
Interesting. When installing autoconf, MacPorts also installs a newer m4
than the system provided one too.
I wonder if there's a better way to cope with this m4 related failure scenario,
than the text presently being given?
I'm sure there is, but is it worth it?
If lots of developers hit this, then maybe...
For now, your best bet might be to build the latest versions
of those tools yourself, e.g., via this script:
http://people.redhat.com/meyering/autotools-install
Once you've downloaded it, run
bash autotools-install --help
8:33 a.m.
On 30/11/2010, at 1:26 AM, Jim Meyering wrote:
Justin Clift wrote:
> On 30/11/2010, at 12:35 AM, Matthias Bolte wrote:
>> Looks like the system is missing pkg-config, or at least has the .m4
>> file is in an unexpected place so that autoconf can't find it.
>>
>> bootstrap checks for pkg-config, so the binary is probably there, but
>> that doesn't mean that autoconf can find the corresponding .m4 file,
>> if it's there at all.
>
> Interesting. When installing autoconf, MacPorts also installs a newer m4
> than the system provided one too.
>
> I wonder if there's a better way to cope with this m4 related failure scenario,
> than the text presently being given?
I'm sure there is, but is it worth it?
Yep, good point. If the solution is easy, that would be nifty.
In practical terms, it just means a MacPort for libvirt will have the MacPort
autoconf and automake as dependencies. All pretty easy (when I get around
to that).
If lots of developers hit this, then maybe...
For now, your best bet might be to build the latest versions
of those tools yourself, e.g., via this script:
http://people.redhat.com/meyering/autotools-install
Once you've downloaded it, run
bash autotools-install --help
Thanks Jim. :)
5:51 p.m.
On 11/29/2010 06:23 AM, Justin Clift wrote:
Hi Eric,
Just ran ./autogen.sh on an OSX box with only the system provided
autotools installed, and got this:
************************************************************************************
Copying file po/remove-potcdate.sin
./bootstrap: patching m4/gettext.m4 to remove need for intl/* ...
./bootstrap: glibtoolize -c -f ...
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
glibtoolize: copying file `build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
./bootstrap: aclocal -I gnulib/m4 --force -I m4 ...
configure.ac:13: warning: macro `AM_SILENT_RULES' not found in library
Warning, but harmless. We might be able to silence it by doing:
m4_apply([AM][_SILENT_RULES], [[yes]])
in configure.ac instead of our direct call to
AM_SILENT_RULES([yes])
./bootstrap: autoconf --force ...
configure.ac:60: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Hmm. This error seems independent of whether pkg-config is correctly
installed - it is complaining about a missing autoconf macro. What
version of automake and autoconf are installed to begin with? Bootstrap
documents that we require 2.59, and 2.59 does provide AC_MSG_ERROR, so I
can't figure out how it isn't getting expanded. But bootstrap shouldn't
have let you get this far if autoconf was older than 2.59. About the
only other thing I can think to do is add AC_PREREQ([2.59]) near the
beginning of configure.ac to give up early if autoconf is too old but
got past the bootstrap check anyway. But if your autoconf version
really is too old, it would be better to patch bootstrap to get the
version check right.
configure.ac:512: error: possibly undefined macro: AC_MSG_NOTICE
Same category as AC_MSG_ERROR.
configure.ac:627: error: possibly undefined macro: PKG_CHECK_MODULES
Yep, back to the analysis of not finding pkg-config .m4 files. Maybe
it's a matter of aclocal not looking in the correct directories for
installed .m4 files?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:04 a.m.
(resending, missed including the list first time. Also reworded some bits)
On 30/11/2010, at 10:51 AM, Eric Blake wrote:
On 11/29/2010 06:23 AM, Justin Clift wrote
> configure.ac:13: warning: macro `AM_SILENT_RULES' not found in library
Warning, but harmless. We might be able to silence it by doing:
m4_apply([AM][_SILENT_RULES], [[yes]])
in configure.ac instead of our direct call to
AM_SILENT_RULES([yes])
Sounds like it would be a harmless thing to add, so yeah, we should probably
give that a shot.
> ./bootstrap: autoconf --force ...
> configure.ac:60: error: possibly undefined macro: AC_MSG_ERROR
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
Hmm. This error seems independent of whether pkg-config is correctly
installed - it is complaining about a missing autoconf macro. What
version of automake and autoconf are installed to begin with? Bootstrap
documents that we require 2.59, and 2.59 does provide AC_MSG_ERROR, so I
can't figure out how it isn't getting expanded. But bootstrap shouldn't
have let you get this far if autoconf was older than 2.59. About the
only other thing I can think to do is add AC_PREREQ([2.59]) near the
beginning of configure.ac to give up early if autoconf is too old but
got past the bootstrap check anyway. But if your autoconf version
really is too old, it would be better to patch bootstrap to get the
version check right.
Just uninstalled the MacPorts version of autoconf, automake, and m4.
These are the system provided versions:
$ which autoconf
/usr/bin/autoconf
$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>;.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
$ which automake
/usr/bin/automake
$ /usr/bin/automake --version
automake (GNU automake) 1.10
Written by Tom Tromey <tromey(a)redhat.com>
and Alexandre Duret-Lutz <adl(a)gnu.org>.
Copyright 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ which m4
/usr/bin/m4
$ /usr/bin/m4 --version
GNU M4 1.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Rene' Seindal.
> configure.ac:512: error: possibly undefined macro: AC_MSG_NOTICE
Same category as AC_MSG_ERROR.
> configure.ac:627: error: possibly undefined macro: PKG_CHECK_MODULES
Yep, back to the analysis of not finding pkg-config .m4 files. Maybe
it's a matter of aclocal not looking in the correct directories for
installed .m4 files?
Aha, interesting. It looks like pkg-config wasn't installed on the system when I
first ran
that command. (this gave the reported error)
Though, after installing pkg-config though MacPorts (version 0.25), exact same problem
and error.
After installing the MacPorts version of m4 (1.4.15) again, noticed it's named
"gm4", rather
than "m4". Wonder if that has any bearing on things?
As I know that installing the MacPorts version of autoconf, automake, and pkg-config
together
allow it to work, I've looked if there's a clear "break point" on the
way from broken to working:
1) Installing autoconf (2.68) when m4 and pkg-config are already installed, also
installs:
+ p5-locale-gettext (1.05-3)
+ help2man (1.38.2)
Autogen.sh still barfs in the same spot, but a bunch of other output messages before it
now,
seeming to be libtool related.
There are two system provided libtools. The OSX /usr/bin/libtool, and the GNU
/usr/bin/glibtool (2.2.4).
2) Installed automake (1.11.1), and that allowed ./autogen.sh to run. (barfs later on due
to
missing GnuTLS, but easily fixable). Didn't need to also install the MacPorts
libtool.
Really looks like the MacPort install of automake is needed, and probably autoconf. But,
it might not be the version causing breakage, rather than macros or something not being
available otherwise. Wonder how easy it would be to identify the needed one(s), and then
add an explicit test to autogen.sh or the bootstrap?
+ Justin
5108
days inactive
5109
days old
6 comments
4 participants
participants (4)
-
Eric Blake -
Jim Meyering -
Justin Clift -
Matthias Bolte