Symbol visibility problems with -std=

Symbol visibility problems with -std=

[Pavel Fedin]

 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

Re: Symbol visibility problems with -std=

[Marco Atzeri]

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

Re: Symbol visibility problems with -std=

[Csaba Ráduly]

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)

Re: Symbol visibility problems with -std=

[Yaakov Selkowitz]

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