Comments (12)
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 apple/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.
from swift.
@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.
from swift.
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.
from swift.
FYI: setjmp.h
is omitted by wasi-libc because of WebAssembly limitation. https://github.com/swiftwasm/wasi-libc/blob/6f0e5680720bcb3ead62b71ea1bf9e6d50173dd1/Makefile#L294
from swift.
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)
from swift.
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?
from swift.
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
from swift.
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.
from swift.
Upstream probably just forgot about the C++ setjmp headers... modules is what is causing it to break and that is rare to use
from swift.
My vote would be to drop pthread and match what WASI is doing, but I don’t really know what I am talking about
from swift.
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.
from swift.
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.
from swift.
Related Issues (20)
- Cannot import the main module of a executable in the test module HOT 3
- Seems async `Task` doesn't work HOT 6
- Add symbol renaming support to wasm-ld like `--alias` or `--defsym`
- Cannot run the DEVELOPMENT-SNAPSHOT-2023-04-25-a toolchain on macOS HOT 1
- Branch cut for 5.9 release HOT 3
- SwiftWASM REPL - allow import of WebAssembly.Memory
- Remove pthread hack HOT 1
- Roadmap: Threading Support
- Roadmap: Component Model Support HOT 2
- Unable to use newer Xcode than SwiftWasm toolchain's Swift version HOT 2
- Support WASILibc in SwiftPM's test runner HOT 2
- Overlay Swift resource directories upon wasi-sysroot
- SwiftDriver: Propagate `-use-static-resource-dir` for module merging job HOT 1
- SwiftWasm 5.9 release HOT 11
- Set up 5.10 release snapshot
- Remove mutex reference from icuuc HOT 1
- `undefined symbol: __stack_chk_guard` on Ubuntu 20.04 aarch64 HOT 2
- Compiler started crashing while building our XCTest HOT 2
- WASM files are quite large? HOT 2
- Cannot import Foundation on DEVELOPMENT channel HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swift.