On 12/13/2017 01:21 PM, richard parkins wrote: > I can now get as far as producing a configure shell script, but if I run it, I get > ./configure: line 14206: syntax error near unexpected token `2.26.0,' > ./configure: line 14206: `AM_PATH_GLIB_2_0(2.26.0, HAVE_GLIB=yes, as_fn_error $? "Missing glib" "$LINENO" 5, gthread)' Generally, when I see an error like that, my first guess is that you don't have pkgconfig and/or the glib devel package installed (in many distros, development files are often a separate package from the more-basic runtime files, so just because you have glib installed does not mean you have the glib development files). Since the string 'AM_PATH_GLIB' appears only once in nbd.git's configure.ac, and not in any .m4 files, it means that nbd is relying on that macro to be provided by a pre-installed third-party library. (Don't get me started on the poor name of that macro - the AM_ namespace is supposed to be for macros provided by automake, but automake does not provide AM_PATH_GLIB) Most likely, your build environment is lacking those dependencies. Not every distro names their packages the same, so I can't always tell you want package to install; but on Fedora 27, glib2-devel-2.54.2-1.fc27.x86_64 provides /usr/share/aclocal/glib-2.0.m4 which provides AM_PATH_GLIB. > > I get the same error if I run the configure in the extracted tarball. > AM_PATH_GLIB_2_0 was in the warning I got from autoreconf -i: > rparkins@rparkins64:~/Downloads/nbd> autoreconf -i > configure.ac:264: warning: macro 'AM_PATH_GLIB_2_0' not found in library Yep, that was autoreconf (well, aclocal run as part of autoreconf) trying to tell you that it was building a corrupt configure file because your development environment is incomplete. Can we make the error message a bit nicer than a corrupted configure file? Probably. (In fact, if we were to use m4_pattern_forbid([AM_PATH_GLIB]) in configure.ac, it would make failure to find the third-party library a hard error that refuses to generate configure, rather than a soft error that only shows up later during the run of ./configure). And yes, I agree that documenting that dependency somewhere in nbd.git would be worthwhile. I don't know nbd.git well enough to know if glib devel packages are also a hard requirement when building from a non-corrupt configure, or if building from a tarball can gracefully degrade into a partial build of only the portions that do not depend on glib. That's why I'm hoping Wouter will chime in; although you may have to wait a few days (this list tends to have activity in spurts, based on when various developers have free time to tend to it). [Also, on technical lists, it's better to avoid top-posting] -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature