On Mon, Sep 20, 2021 at 08:21:27PM +0300, Adrian Bunk wrote: > On Mon, Sep 06, 2021 at 12:57:10AM +0100, Simon McVittie wrote: > > On Thu, 31 Dec 2020 at 14:28:53 +0000, Matthias Klose wrote: > > > The package fails to build in a test rebuild on at least amd64 with > > > autoconf 2.70, but succeeds to build with autoconf 2.69. > > ... > > > The full build log can be found at: > > > http://qa-logs.debian.net/2020/09/26.ac270/ripperx_2.8.0-2_unstable_ac270.log > > > The last lines of the build log are at the end of this report. > > > > I don't think those lines indicate the actual error, which looks like a C++ > > compiler problem (perhaps because the new Autoconf version passes options > > that make the compiler more strict?): > >... > > This new error might be an Autoconf bug: the second check (with -lutil) > > looks like it's missing an extern "C" on the prototype. If so, > > http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=b27bc3e230bb12fdd9a813e38e82bc4c3e22b4cc > > might help. > > This commit is not sufficient, and the root cause is that > AC_PROG_CC([g++]) is documented to be no longer supported: > https://sources.debian.org/src/autoconf/2.71-2/NEWS/#L90
The problem is that ripperx is giving C++ sources a .c file extension. The correct fix is: AC_PROG_CC([g++]) -> AC_PROG_CC And then rename all C++ files foo.c -> foo.cc with corresponding changes in Makefile.am. This results in automake automatically choosing the C++ compiler, without any need to pretend it was a C compiler. > cu > Adrian cu Adrian
