Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prepare libclang_rt.builtins-wasm32.a on wasm32-wasi-threads #543

Open
oligamiq opened this issue Sep 29, 2024 · 4 comments · May be fixed by WebAssembly/wasi-sdk#494
Open

prepare libclang_rt.builtins-wasm32.a on wasm32-wasi-threads #543

oligamiq opened this issue Sep 29, 2024 · 4 comments · May be fixed by WebAssembly/wasi-sdk#494

Comments

@oligamiq
Copy link

Would you prepare libclang_rt.builtins-wasm32.a for wasm32-wasi-threads? In the wasi-sdk-24.0-x86_64-linux/lib/clang/18/lib, only wasi, wasip1, and wasip2 exist.

I manually linked libclang_rt.builtins-wasm32.a from wasip1, which resolved the issue, but I encountered:

(import "env" "__floatunditf" (func $fimport$2 (param i32 i64)))
(import "env" "__floatditf" (func $fimport$3 (param i32 i64)))

It seems that clang is unable to link libclang_rt.builtins-wasm32.a.

@abrown
Copy link
Collaborator

abrown commented Oct 3, 2024

__floatunditf and __floatditf seem unrelated to threads and from the imports you mention it looks like they're using a module name I would expect Emscripten to satisfy. Maybe you can explain a bit more what you're trying to do? I'm trying to understand it but have to guess (e.g., are those imports unresolved? Where do you see that error?)

@oligamiq
Copy link
Author

oligamiq commented Oct 4, 2024

I apologize for my poor English.
When I tried to build, the following imports remained and prevented execution:

(import "env" "__floatunditf" (func $fimport$2 (param i32 i64)))
(import "env" "__floatditf" (func $fimport$3 (param i32 i64)))

However, by linking libclang_rt.builtins-wasm32.a for wasip1, it was resolved and the program ran successfully.
In other words, it seems that clang is not linking libclang_rt.builtins-wasm32.a when building for wasm32-wasip1-threads.

@abrown
Copy link
Collaborator

abrown commented Oct 10, 2024

I think I resolved this in WebAssembly/wasi-sdk#494, but to check the fix can you do the following:

  • create the directory wasi-sdk-24.0-x86_64-linux/lib/clang/18/lib/wasip1-threads
  • copy libclang_rt.builtins-wasm32.a from one of the sibling directories (e.g., .../lib/wasip1) into wasip1-threads
  • compile as before without the manual linking

Do you still see the issue?

abrown added a commit to abrown/wasi-sdk that referenced this issue Oct 17, 2024
This uses the `__floatditf` function which was reported as an issue in
[wasi-libc#543]. Compiling and running this test should prove that the
builtins are available in the `wasm32-*-threads` targets as long as the
tests use those targets (they do, right?).

[wasi-libc#543]: WebAssembly/wasi-libc#543
abrown added a commit to abrown/wasi-sdk that referenced this issue Oct 18, 2024
This uses the `__floatditf` function which was reported as an issue in
[wasi-libc#543]. Compiling and running this test should prove that the
builtins are available in the `wasm32-*-threads` targets as long as the
tests use those targets (they do, right?).

[wasi-libc#543]: WebAssembly/wasi-libc#543
oligamiq added a commit to oligamiq/cargo that referenced this issue Nov 5, 2024
oligamiq added a commit to oligamiq/rust that referenced this issue Nov 5, 2024
@oligamiq
Copy link
Author

oligamiq commented Nov 6, 2024

I apologize for the delay, but it seems that the issue was on my end. However, when I configured it to use clang, the object being linked appears to be wasi-sdk-24.0-x86_64-linux/lib/clang/18/lib/wasi/libclang_rt.builtins-wasm32.a. I believe this is not an appropriate linking target when setting the target to wasip1-threads, so I suggest making adjustments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants