autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8

[Chaim Zax]

Hi, autoconf developers, Debian gcc maintainers,

In Debian there is a bug [1] reported on the autoconf package which
relates to a change in gcc 8. After looking into the issue it's not
completely clear to me what the best solution should be.

The autoconf function AC_SEARCH_LIBS check the availability of a
specific library by generating and compiling a small c++ program. From
gcc version 8 on this seems to fail for some libraries (e.g. atomic),
but not all (we haven't seen major fallout so far).

To reproduce this issue the following configure.ac script can be used:

$ cat configure.ac
AC_INIT
AC_PROG_CXX
AC_LANG([C++])
AC_SEARCH_LIBS([__atomic_load_8],[atomic])

$ autoconf


When configured (build) with g++ 7 the result is correct, as expected:

$ CXX=g++-7 ./configure
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-7 accepts -g... yes
checking for library containing __atomic_load_8... -latomic


But when configured (build) with g++ 8 the atomic library is not found:

$ CXX=g++-8 ./configure
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-8 accepts -g... yes
checking for library containing __atomic_load_8... no


The c++ file generated is:

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char __atomic_load_8 ();
int
main ()
{
return __atomic_load_8 ();
  ;
  return 0;
}


When compiled with g++ 7 it only gives a warning, the function arguments
of '__atomic_load_8' are missing:

$ g++-7 -o conftest -g -O2   test.cpp -latomic
test.cpp:16:6: warning: new declaration ‘char __atomic_load_8()’
ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
volatile void*, int)’ [-Wbuiltin-declaration-mismatch]
 char __atomic_load_8 ();
      ^~~~~~~~~~~~~~~


When compiled with g++ 8 it fails with an compilation error, the missing
arguments are now resulting in an error:

$ g++-8 -o conftest -g -O2   test.cpp -latomic
test.cpp:16:6: error: new declaration ‘char __atomic_load_8()’
ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
volatile void*, int)’ [-fpermissive]
 char __atomic_load_8 ();
      ^~~~~~~~~~~~~~~
test.cpp: In function ‘int main()’:
test.cpp:20:25: error: too few arguments to function ‘long unsigned int
__atomic_load_8(const volatile void*, int)’
 return __atomic_load_8 ();


This error is interpreted by autoconf, which concludes the library is
not available. When the generated c++ file is changed to use a different
function from different library (e.g. the 'exp' function from 'libm')
the file [2] does compile with c++ 8.

$ g++-8 -o conftest -g -O2   exp.cpp -latomic
exp.cpp:16:6: warning: declaration of ‘char exp()’ conflicts with
built-in declaration ‘double exp(double)’ [-Wbuiltin-declaration-mismatch]
 char exp();
      ^~~


To know the impact of this bug on other Debian packages it's important
to know when g++ will produce an error, and when only a warning. We
suspect only the libraries provided by gcc itself seem to produce this
error (although we haven't investigated that further), otherwise it
would be likely lots of other Debian packages would produce this error
as well. Perhaps someone knows exactly when g++ triggers this error, and
possibly on which libraries? When updating autoconf it might be
interesting to know if there is a compilation flag to change this error
to a warning.

To fix this issue it's most likely autoconf itself that needs to be
updated as well. If this check only fails on libraries provided with g++
the usage of the AC_SEARCH_LIBS function is probably not needed at all
to check the availability on these libraries, Debian's package
dependencies will automatically make sure these libraries will be
available when autoconf is installed.

Because autoconf can be used outside a Debian environment this solution
might not work for everyone. Perhaps the AC_SEARCH_LIBS function should
be extended so function arguments needed to check a library could be
provided as well, or perhaps there is an other way to make it compatible
with g++ 8.

Regards,
Chaim Zax & Paul

p.s. I'm not an autoconf developer, currently working at the BSP in
Venlo (https://wiki.debian.org/BSP/2019/01/nl/Venlo)


[1] https://bugs.debian.org/907277

[2] contents of the exp.cpp file from above:

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char exp();
int
main ()
{
return exp();
  ;
  return 0;
}

signature.asc
Description: OpenPGP digital signature