On 12/06/2012 06:04 AM, Colin Watson wrote: > lftp fails to build with current gnulib. I can't figure out whether > this is a gnulib bug or an lftp bug. To reproduce, on a system with > glibc 2.16 (I'm using the current Ubuntu development branch, "raring") > and lftp's build-dependencies: > > git clone git://github.com/lavv17/lftp.git > cd lftp > PATH="/path/to/current/gnulib/checkout:$PATH" ./autogen.sh > make > > The output is attached. The problem appears to be that gets is declared > in C++, but then C code is compiled using the results from C++ tests.
That's indeed a problem, as latest glibc no longer declares gets() in C,
but still declares it in C++.
>
> Is gnulib misbehaving here, or is lftp? If the latter, what would be a
> reasonable fix? I assume that lftp has a reason for running gnulib's
> tests under C++ ...
Why is lftp using C++ for configure but not at compile time? The
configure tests should match the compilation environment?
I'm not sure if we need to do something in gnulib, or if the bug really
is in lftp; but meanwhile, I have a suggestion that might solve your
problem. Add this to lftp's configure.ac:
dnl POSIXCHECK is worthwhile for maintainers, but adds several seconds
dnl (more than 10% execution time) to ./configure, with no benefit for
dnl most users. Using it to look for bugs requires:
dnl GNULIB_POSIXCHECK=1 autoreconf -f
dnl ./configure
dnl make
dnl make -C src clean
dnl make CFLAGS=-DGNULIB_POSIXCHECK=1
m4_syscmd([test "${GNULIB_POSIXCHECK+set}" = set])
m4_if(m4_sysval, [0], [], [dnl
gl_ASSERT_NO_GNULIB_POSIXCHECK])
and that should make gnulib quit checking whether gets() is declared in
the first place.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
