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?


Reply via email to