From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 039443851C19 for ; Wed, 13 May 2020 14:08:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 039443851C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=yselkowitz@cygwin.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-450-dwfyhbF1OrOOdK97g-lXiQ-1; Wed, 13 May 2020 10:08:03 -0400 X-MC-Unique: dwfyhbF1OrOOdK97g-lXiQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A43D7846377 for ; Wed, 13 May 2020 14:08:02 +0000 (UTC) Received: from ovpn-113-5.rdu2.redhat.com (ovpn-113-5.rdu2.redhat.com [10.10.113.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 50E025C49B for ; Wed, 13 May 2020 14:08:02 +0000 (UTC) Message-ID: <84fe3a8506e720b5d7f131affaa95684cf8a3285.camel@cygwin.com> Subject: Re: Symbol visibility problems with -std= From: Yaakov Selkowitz To: cygwin@cygwin.com Date: Wed, 13 May 2020 10:08:00 -0400 In-Reply-To: <00a001d62910$4120ea20$c362be60$@samsung.com> References: <00a001d62910$4120ea20$c362be60$@samsung.com> User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 14:08:10 -0000 On Wed, 2020-05-13 at 13:21 +0300, Pavel Fedin via Cygwin wrote: > While compiling various software packages for Cygwin i notice that very = often i have to add something like #define _GNU_SOURCE to > them in order to compile correctly. Meanwhile on Linux they compile with = no problems at all. I've narrowed it down to -std=3D??? > option using a simple test case: [snip] > $ g++ test.cpp -o test - compiles OK > $ g++ test.cpp -o test -std=3Dc++14 - error: 'strdup' was not declared in= this scope; did you mean 'strcmp'? >=20 > By printing out predefined macros (-dM -E) i found out that -std=3Dsomet= hing option adds " #define __STRICT_ANSI__ 1" to builtin > macros, but removes all *_SOURCE definitions, so _DEFAULT_SOURCE is not t= riggered any more. That is what -std=3Dc* is supposed to mean, that you are declaring strict ISO-standard language conformance. > I've compared the behavior with Linux system. On Linux -std=3Dc++14 also= defines __STRICT_ANSI__, but various *_SOURCE macros are not > omitted. That's because _GNU_SOURCE is defined unconditionally by g++ on Linux, which overrides the __STRICT_ANSI__ defined by -std=3Dc*. IIUC this is done only to handle the use of non-ISO functions in libstdc++, particularly in the implementation of newer C++ standards. The bottom line is, if you are using POSIX C extensions, then you shouldn't be declaring -std=3Dc* without the appropriate _*_SOURCE. > Isn't this a Cygwin bug? Not really, just that our g++ is somewhat more strict. If anything, allowing use of functions outside the declared standards (the behaviour on Linux) is the bug, and it's been on my to-do list for a long time to fix. Fixing this isn't as simple as removing the unconditional define; the C library functions used by newer C++ need to be appropriately guarded, and then those specific guards used in libstdc++. It was a major project to get this working on Cygwin. > By the way, clang does not suffer from this problem. Clang also defines _GNU_SOURCE unconditionally when compiling C++, even on Cygwin. Perhaps *that* should be considered the bug. -- Yaakov