* Symbol visibility problems with -std=
[not found] <CGME20200513102124eucas1p20b619bf7b82b386c66e935199790b2c1@eucas1p2.samsung.com>
@ 2020-05-13 10:21 ` Pavel Fedin
2020-05-13 12:12 ` Marco Atzeri
2020-05-13 14:08 ` Yaakov Selkowitz
0 siblings, 2 replies; 4+ messages in thread
From: Pavel Fedin @ 2020-05-13 10:21 UTC (permalink / raw)
To: cygwin
Hello everyone!
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:
--- cut test.cpp ---
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
char *p = strdup("hello");
printf("%s\n", p);
free(p);
return 0;
}
--- cut test.cpp ---
$ 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.
I've compared the behavior with Linux system. On Linux -std=c++14 also defines __STRICT_ANSI__, but various *_SOURCE macros are not
omitted.
Isn't this a Cygwin bug? By the way, clang does not suffer from this problem.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Symbol visibility problems with -std=
2020-05-13 10:21 ` Symbol visibility problems with -std= Pavel Fedin
@ 2020-05-13 12:12 ` Marco Atzeri
2020-05-13 13:22 ` Csaba Ráduly
2020-05-13 14:08 ` Yaakov Selkowitz
1 sibling, 1 reply; 4+ messages in thread
From: Marco Atzeri @ 2020-05-13 12:12 UTC (permalink / raw)
To: cygwin
Am 13.05.2020 um 12:21 schrieb Pavel Fedin via Cygwin:
> Hello everyone!
>
> 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:
> --- cut test.cpp ---
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> int main(void)
> {
> char *p = strdup("hello");
>
> printf("%s\n", p);
> free(p);
> return 0;
> }
> --- cut test.cpp ---
>
> $ 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.
> I've compared the behavior with Linux system. On Linux -std=c++14 also defines __STRICT_ANSI__, but various *_SOURCE macros are not
> omitted.
> Isn't this a Cygwin bug? By the way, clang does not suffer from this problem.
>
> Kind regards,
> Pavel Fedin
strdup is an extension of C standard
so strictly behaviour of Cgywin is correct, see
/usr/include/sys/features.h
for details
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Symbol visibility problems with -std=
2020-05-13 12:12 ` Marco Atzeri
@ 2020-05-13 13:22 ` Csaba Ráduly
0 siblings, 0 replies; 4+ messages in thread
From: Csaba Ráduly @ 2020-05-13 13:22 UTC (permalink / raw)
To: cygwin
On 13/05/2020 14:12, Marco Atzeri via Cygwin wrote:
> Am 13.05.2020 um 12:21 schrieb Pavel Fedin via Cygwin:
(snip code using strdup)
>> $ 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'?
>>
>
>
> strdup is an extension of C standard
>
> so strictly behaviour of Cgywin is correct, see
>
> /usr/include/sys/features.h
>
> for details
Pavel, you may want to try -std=gnu++14 instead.
Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Symbol visibility problems with -std=
2020-05-13 10:21 ` Symbol visibility problems with -std= Pavel Fedin
2020-05-13 12:12 ` Marco Atzeri
@ 2020-05-13 14:08 ` Yaakov Selkowitz
1 sibling, 0 replies; 4+ messages in thread
From: Yaakov Selkowitz @ 2020-05-13 14:08 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-13 14:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20200513102124eucas1p20b619bf7b82b386c66e935199790b2c1@eucas1p2.samsung.com>
2020-05-13 10:21 ` Symbol visibility problems with -std= Pavel Fedin
2020-05-13 12:12 ` Marco Atzeri
2020-05-13 13:22 ` Csaba Ráduly
2020-05-13 14:08 ` Yaakov Selkowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).