Verify SwiftPM dependencies that contain C and C++

[MaxDesiatov]

Such packages don't seem to be successfully building as of DEVELOPMENT-SNAPSHOT-2020-04-06-a

[MaxDesiatov]

One example when buiding OpenCombine:

While building module 'std' imported from .swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-05-a/usr/share/wasi-sysroot/include/c++/v1/stdint.h:123:
In file included from <module-includes>:20:
fatal error: 'setjmp.h' file not found
#include_next <setjmp.h>
              ^~~~~~~~~~
In file included from .build/checkouts/OpenCombine/Sources/COpenCombineHelpers/COpenCombineHelpers.cpp:8:
In file included from .build/checkouts/OpenCombine/Sources/COpenCombineHelpers/include/COpenCombineHelpers.h:11:
: could not build module 'std'
#include_next <stdint.h>
 ~~~~~~~~~~~~~^
2 errors generated.

[kateinoigakukun]

FYI: setjmp.h is omitted by wasi-libc because of WebAssembly limitation. https://github.com/swiftwasm/wasi-libc/blob/6f0e5680720bcb3ead62b71ea1bf9e6d50173dd1/Makefile#L294

[MaxDesiatov]

I understand that, was a bit more confused by this part:

could not build module 'std'
#include_next <stdint.h>

I'm currently trying to fix OpenCombine by enabling conditional target dependencies from swiftlang/swift-package-manager#2428 so that it avoids building COpenCombineHelpers for WASI and uses custom stubs instead, but I'm currently blocked by #645, will try again tomorrow after the next snapshot is built with the latest SwiftPM code.

[MaxDesiatov]

I can confirm that building C++ code does not work with our toolchain, probably due to the inclusion of pthread headers in our builds:

% cat test.cpp
#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

% ~/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/bin/clang++ \
--sysroot=/Users/maxd/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/share/wasi-sysroot \
test.cpp -o test
wasm-ld: error: /Users/maxd/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/share/wasi-sysroot/lib/wasm32-wasi/libc++.a(memory.cpp.obj): 
undefined symbol: pthread_mutex_lock
wasm-ld: error: /Users/maxd/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/share/wasi-sysroot/lib/wasm32-wasi/libc++.a(memory.cpp.obj): 
undefined symbol: pthread_mutex_unlock
wasm-ld: error: /Users/maxd/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/share/wasi-sysroot/lib/wasm32-wasi/libc++.a(condition_variable.cpp.obj): 
undefined symbol: pthread_cond_wait
wasm-ld: error: /Users/maxd/.swiftenv/versions/wasm-DEVELOPMENT-SNAPSHOT-2020-04-28-a/usr/share/wasi-sysroot/lib/wasm32-wasi/libc++.a(condition_variable.cpp.obj): 
undefined symbol: pthread_cond_broadcast
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

[ddunbar]

What I don't understand here is why WASI includes headers which reference setjmp.h, if they exclude it? It may be that these are the compiler's headers, and they are actually what need to be changed?

[ddunbar]

For the setjmp issue specifically, it looks like perhaps setjmp.h, csetjmp and related entries in the module.modulemap for the compiler internal headers should just be removed? I also had to work around a bogus reference to ::signal from csignal

[MaxDesiatov]

Interesting, apparently wasi-sdk omits some headers (including setjmp.h), but doesn't do that for C++ headers? I'll double check.

Also, as far as I know, the only substantial difference between our wasi-sdk fork and the upstream repo is the inclusion of pthread headers. I'm not sure whether we should actually include them, omitting them would require updating a lot more code probably. Maybe it's worth sticking to it and waiting until wasm32/WASI get proper threading support? We do provide pthread stubs, but those are only linked when you build with SwiftPM, which is not applicable for standalone C++ executables like the invocation of clang++ above. Perhaps that's fine, the downside being that our users need to switch their toolchain to something pthread-less like the upstream wasi-sdk just to compile some standalone C++ targeting WASI.

[ddunbar]

Upstream probably just forgot about the C++ setjmp headers... modules is what is causing it to break and that is rare to use

[ddunbar]

My vote would be to drop pthread and match what WASI is doing, but I don’t really know what I am talking about

[MaxDesiatov]

Upstream probably just forgot about the C++ setjmp headers... modules is what is causing it to break and that is rare to use

There's an issue upstream that tracks this inconsistency, doesn't seem like there were any updates recently WebAssembly/wasi-sdk#93

My vote would be to drop pthread and match what WASI is doing, but I don’t really know what I am talking about

That's my vote too, I'd actually prefer to use upstream wasi-sdk directly, but I didn't touch the pthread parts in the first place to speak confidently about it, @kateinoigakukun quite probably knows more about it.

[MaxDesiatov]

Just to confirm, C packages build ok, I've got a fork of zlib (the only change being a Package.swift addition) building now, so it's just C++ package that are problematic due to wasi-sdk not cleaning up their C++ headers.

[kateinoigakukun]

@MaxDesiatov Sorry for waiting a long time for this issue.

In short, you can link pthread things with libswiftWasiPthread.a

$ clang++ main.cpp \
   --sysroot=$(dirname $(swiftenv which swiftc))/../share/wasi-sysroot \
   -L$(dirname $(swiftenv which swiftc))/../lib/swift_static/wasi \
   -lswiftWasiPthread 

But in the long run, it's essential to support pthread in wasi-libc.