[libvirt] Bootstrap fail, but non-useful message :/

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

2010/11/29 Justin Clift <jclift@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

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?

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

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

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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

(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@redhat.com> and Alexandre Duret-Lutz <adl@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
participants (4)
-
Eric Blake
-
Jim Meyering
-
Justin Clift
-
Matthias Bolte