signal header C++/WASI libc inconsistency (WASI SDK 8)

[rene-fonseca]

There is an inconsistency in the signal headers for C++ vs C lib that causes build failure. Tested for WASI SDK 8.

Error from compiler:
/usr/local/wasi-sdk/share/wasi-sysroot/include/c++/v1/csignal:53:9: error: no member named 'signal' in the global namespace; did you mean 'sigval'?
using ::signal;

The WASI clib header (share/wasi-sysroot/include/signal.h) uses __wasilibc_unmodified_upstream to disable signal function:
#ifdef __wasilibc_unmodified_upstream /* WASI has no signals */
void (*signal(int, void (*)(int)))(int);
#endif

But the C++ csignal header (share/wasi-sysroot/include/c++/v1/csignal) refers to signal function always:
_LIBCPP_BEGIN_NAMESPACE_STD
using ::sig_atomic_t;
#ifdef __wasilibc_unmodified_upstream // ADDED BY ME
using ::signal;
#endif // ADDED BY ME
using ::raise;
_LIBCPP_END_NAMESPACE_STD

I just add __wasilibc_unmodified_upstream in csignal as a workaround for my build pipeline but likely better to add fake signal in WASI c lib to avoid modifying C++ llvm header? Not sure what is preferred.

[sbc100]

Interesting. I guess we need to choose between declare functions that don't exist at link time (we do this for raise() for example, although that is probably an oversight) and modifying libstdc++ sources.

Changing upstream libstdc++ is probably right way to go long term.

Alternatively, perhaps the best solution would be to simply remove signal.h and csignal completely from the SDK since we don't support any of the functions therein.

[abrown]

Signals are now completely removed; this can be closed, right?