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

- Raw text -