[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruno Haible
Subject: Re: isnan function conflicts with C++ standard library declarations
Date: Wed, 28 Aug 2019 18:13:26 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-159-generic; KDE/5.18.0; x86_64; ; )

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__

> >> 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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]