Error "sigemptyset was not declared in this scope" when using C+11 and Newlib

Question

We are catching compiler errors when using sigemptyset on Cygwin under Newlib. The error occurs with a C++ compiler, but only when -std=XXX is used. Without a standard option, the test program compiles and executes as expected.

The test program is below, and the Cygwin header of interest follows. I don't see anything suspicious in the Cygwin header.

I've tried tricks like #define _GNU_SOURCE and #define _XOPEN_SOURCE 700. I've also tried tricks like using the global and std namespaces. Related, see What does -D_XOPEN_SOURCE do/mean? and Namespace issues in c++11?.

What is causing the compile failure and how do I fix it?

---

$ cat ~/test.cxx 
#include <signal.h>

int main(int argc, char* argv[])
{
    struct sigaction new_handler;
    return sigemptyset(&new_handler.sa_mask);
}

Without a -std=XXX, it results in:

$ g++ -c test.cxx
$

With a -std=XXX, it results in:

$ g++ -std=c++03 -c test.cxx
test.cxx: In function int main(int, char**):
test.cxx:6:44: error: sigemptyset was not declared in this scope
  return sigemptyset(&new_handler.sa_mask);

And when trying to use sigemptyset in the global namespace:

$ g++ -std=c++03 -c test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:6:12: error: ‘::sigemptyset’ has not been declared
     return ::sigemptyset(&new_handler.sa_mask);
            ^

Things get worse when using -std=gnu++03 and friends.

Rackety

My guess? When you use plain C++ standard without GNU extensions, you need to define _XOPEN_SOURCE before including <signal.h>. – Shiism

Also, you should be looking in <cygwin/signal.h> for the Cygwin signal header file. – Shiism

Thanks @Joachim. When grepping for sigemptyset there are two hits: (1) /usr/include/bash/sig.h and (2) /usr/include/sys/signal.h. – Rackety

I didn't tell you to include <cygwin/signal.h> directly, instead it's a file you need to look at for Cygwin-specific things. Like for example what macros are needed to be defined before you include <signal.h>. – Shiism

Answer 1

The issue was worked through at Botan 2.1.0 does not compile under Cygwin 2.8.0 with g++ 5.4.0. Here are the two comments of interest.

First, from noloader:

Cygwin uses Newlib, not GNU's libstdc++. When there's no -std=c++XX, current GCC defaults to -std=gnu++11 (GCC 6 changes to gnu++14 by default). I believe GNU sources ensures expected functions, like sigaction, are available.

You might consider trying -D_XOPEN_SOURCE=600 or -D_XOPEN_SOURCE=700.

Also see C++ and feature guards Warning Question on the Newlib mailing list.

Second, from SideChannel:

Thanks to @noloader. Until now -std=c++11 was set in Makefile. The important info is in above mentioned thread on the Newlib mailing list. Yaakov Selkowitz wrote:

G++ defines _GNU_SOURCE on glibc targets, meaning that -std=c++NN is, contrary to the documentation, not strict ISO C++:

So, applying the patch #987 AND setting -std=gnu++11 works for me. I did not try the other -D options (I think the other fact is more fundamental). Summarizing, @randombit please apply the PR #987 and set -std=gnu++11 for gcc under Cygwin.

Rackety

Answer 2

The function is an extension over the ISO C standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigemptyset.html

as such is protected on /usr/include/sys/signal.h by
__XSI_VISIBLE >= 4

see /usr/include/sys/features.h for details.

As defaults the largest definition set is used, but -std=XXX reduces the definition scope

Bipropellant

Thanks Matzeri. Its interesting the way the issue surfaces. It seems like everything should fail, or everything should succeed. At minimum, it seems like -std=gnu++XX should have compiled along with no -std since neither are ISO C. If I recall correctly, some -std=gnu++XX is a default when using GCC's C++ compiler. I guess its the way newlib does things since its not present in libstdc++. – Rackety

newlib headers are under re-shuffle. There were notable changes in the last months and /usr/include/sys/features.h provide the current guidelines. – Bipropellant

so.... what's the solution? – Mackay

@Mackay #define _GNU_SOURCE should work to have the largest scope. – Bipropellant