Re: Cannnot build nbd from git clone
On Wed, Dec 13, 2017 at 05:13:34PM -0600, Eric Blake wrote:
> 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.
Yeah.
When I first started using glib, I wasn't aware of pkg-config and all
that requires, and at the time the first macro I found to help me figure
out where glib was, was that one.
We're using pkg-config these days to figure out where GnuTLS is, so
might as well migrate glib to that, too.
> > 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.
Indeed.
> 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).
Might be useful to look at that, but I think switching to pkg-config is
probably a better long-term strategy.
> 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
Yes. The configuration file is parsed with glib, we use the threadpool
implementation from gthread (which is merged into glib these days), and
we have various hashtables that use the glib implementation, too. It's
not optional.
At least not for the server. The glib bits are not used in the client,
because that sometimes needs to be run from initramfs, and then you
don't want huge dependencies. That only requires GnuTLS (optionally),
libc, and libnl-genl these days.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: