Re: lftp fails to build with current gnulib: 'gets' undeclared here

[Eric Blake]

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