Re: isnan function conflicts with C++ standard library declarations

["Martin Storsjö" <martin@martin.st>]

Hi Bruno,

On Wed, 28 Aug 2019, Bruno Haible wrote:

> Hi Martin,
>
>> Well in addition to macOS, I can also still reproduce the issue on Linux
>> (Ubuntu 18.04, with its default GCC 7) as well, so maybe it's an issue
>> with newer C++ standard headers, regardless of platform?
>
> Indeed. I can reproduce it with GCC >= 6. And since clang sometimes uses the
> C++ header files from GCC, we also have to enable the workaround for clang.
> It is apparently not needed with AIX xlc, HP-UX cc, Solaris cc.
>
> Fixed by changing the condition to
>  #if __GNUC__ >= 6 || defined __clang__

Thanks! That should probably work, and good to know in which GCC version 
this changed.

>>>> This issue can crop up e.g. when trying to build gettext for mingw (which
>>>> has got the gnulib isnan function bundled, even if it isn't used).
>>>
>>> I'm regularly building gettext on mingw and haven't seen this issue. Therefore
>>> thanks again for the reproduction example.
>>
>> I ran into it while trying to build gettext with clang (with my pure-llvm
>> based toolchain, at https://github.com/mstorsjo/llvm-mingw in case you're
>> interested), so I presume there's something that goes different in gettext
>> with clang/lld compared to gcc
>
> Yes. It would make sense to compare the config.status file generated by an llvm
> build with those generated by a gcc build.

Thanks for the pointers - I'll see if I'll dig further into that to see 
what the differences stem from.

>> I only run into it
>> if building a shared gettext, not with a static-only build, for some
>> reason.
>
> The reason is that gettext is written in C, and only a few files are getting
> compiled by a C++ compiler, as a workaround to a problem with DLL import of
> variables and variable initializers. This workaround is not enabled when
> --disable-shared is specified.

Ah, thanks, that explains things a bit.

// Martin