Re: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8
On 12.01.19 21:37, Chaim Zax wrote:
> 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.
g++ 8 got more strict. You could check if that's the case for g++ 9 as well (or
gcc-snapshot). In any case, autoconf should be adjusted to avoid the warning/error.
> 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;
> }
>
Reply to: