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