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

[Martin Storsjö]

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