X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 27E78393F054
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1589378892;
	bh=JN06WKIM3CDG6VvlzDDeK2OCBsR7iX+caBRoIhaBS5E=;
	h=Subject:From:To:Date:In-Reply-To:References:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From;
	b=KwNTKV66xPS+8xMjVB2J1RfHbI/Teoqtv3rYzO9zFJomN3Vpqr06xr3DcTqUhLwn+
	 NQrnTMrtogp/Vz9f5AvcH0fGgUBlMNJ/2u3s9mMrDywRsmAZatGgA8KnM9rKxN4iSo
	 ggkasefS265wsj/u8SxvyroL87m89bE99sheODL8=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
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 AT cygwin DOT com
X-MC-Unique: dwfyhbF1OrOOdK97g-lXiQ-1
Message-ID: <84fe3a8506e720b5d7f131affaa95684cf8a3285.camel@cygwin.com>
Subject: Re: Symbol visibility problems with -std=
From: Yaakov Selkowitz <yselkowitz AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Date: Wed, 13 May 2020 10:08:00 -0400
In-Reply-To: <00a001d62910$4120ea20$c362be60$@samsung.com>
References: <CGME20200513102124eucas1p20b619bf7b82b386c66e935199790b2c1 AT eucas1p2 DOT samsung DOT com>
 <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
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 AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <http://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <http://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

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=???
> option using a simple test case:
[snip]
> $ g++ test.cpp -o test - compiles OK
> $ g++ test.cpp -o test -std=c++14 - error: 'strdup' was not declared in this scope; did you mean 'strcmp'?
> 
>  By printing out predefined macros (-dM -E) i found out that -std=something option adds " #define __STRICT_ANSI__ 1" to builtin
> macros, but removes all *_SOURCE definitions, so _DEFAULT_SOURCE is not triggered any more.

That is what -std=c* is supposed to mean, that you are declaring strict
ISO-standard language conformance.

>  I've compared the behavior with Linux system. On Linux -std=c++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=c*.  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=c* 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


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple