From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3A8231F461 for ; Wed, 28 Aug 2019 20:23:26 +0000 (UTC) Received: from localhost ([::1]:42276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i34TV-0007FB-7t for normalperson@yhbt.net; Wed, 28 Aug 2019 16:23:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46551) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i33z1-0007XB-7Z for bug-gnulib@gnu.org; Wed, 28 Aug 2019 15:51:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i33yz-0000qa-Hx for bug-gnulib@gnu.org; Wed, 28 Aug 2019 15:51:54 -0400 Received: from mail8.parnet.fi ([77.234.108.134]:20190) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i33yz-0000pS-BG for bug-gnulib@gnu.org; Wed, 28 Aug 2019 15:51:53 -0400 Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id x7SJpm1w029521-x7SJpm20029521 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 Aug 2019 22:51:49 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id x7SJpm76003307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2019 22:51:48 +0300 Date: Wed, 28 Aug 2019 22:51:48 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Bruno Haible Subject: Re: isnan function conflicts with C++ standard library declarations In-Reply-To: <4751172.Ro3qupbQrl@omega> Message-ID: References: <1621444.12XPtTX4uv@omega> <4751172.Ro3qupbQrl@omega> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 77.234.108.134 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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