On 1/17/19, Paul Gevers <elb...@debian.org> wrote: > On 14-01-2019 11:57, Matthias Klose wrote: >> On 12.01.19 21:37, Chaim Zax wrote: >>> 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. > > Do you happen to know why g++ 8 happens to fail on this library and > doesn't fail on other libraries we checked? Does g++ know which > libraries it includes and is it pickier on those?
I'm not familiar with the library in question but the problem appears to be specific to these __atomic_xyz builtins which seem to get special treatment in g++. Other builtins I tested do not exhibit such failures. There is no obvious way to disable the error in GCC: -fno-buitlin appears not to affect these functions and -fpermissive does not resolve the error at the call site. AC_SEARCH_LIBS can present a simple interface based on the assumption that correct declarations are not required to test linking against a particular symbol in a library. Clearly this assumption is not valid for these particular functions in C++ mode, so it is likely that AC_SEARCH_LIBS simply cannot be used to reliably probe for __atomic_xyz functions in libatomic. In that case, configure authors must use an alternate approach. For example, - probing a different function from libatomic, if possible, - probing in C mode, if possible, - using AC_LINK_IFELSE with a valid test program, or - something else? Cheers, Nick