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 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.
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)
- DEVELOPMENT-SNAPSHOT in release version HOT 2
- CI failure: cannot guarantee tail call due to mismatched parameter counts HOT 2
- Enable `swiftasynccall` calling convention with tail-call feature HOT 2
- Workaround wasm platform compiler issue HOT 5
- SwiftWasm 5.10 release HOT 4
- Make Swift SDK host platform independent HOT 2
- Fatal error during compilation (Functions with 'no-prototype' attribute must take varargs) HOT 2
- The test executable fails to run due to call stack exhausted (swift-wasm-DEVELOPMENT-SNAPSHOT-2024-03-22-a) HOT 5
- XCTest requires access to host file system HOT 1
- XMLParser use requires shim to include libxml2.a HOT 3
- Cannot install swift-wasm-DEVELOPMENT-SNAPSHOT-2024-03-30-a-ubuntu20.04_aarch64.artifactbundle.zip HOT 3
- Roadmap: WASI Preview2 Support
- Support Swift SDK in vscode-swift
- Cannot import Foundation when using a host platform independent SDK HOT 6
- undefined symbols (RegexParser) HOT 2
- Thread and RunLoopMode.common in not available on WASM HOT 1
- SwiftWasm 6.0 release
- wasm-ld: error: swiftrt.o: undefined symbol: swift_addNewDSOImage HOT 2
- Overwriting a file with `Data.write(to:)` causes an error
- Embedded Wasm Build Is Needlessly Slow HOT 1
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.