-
Notifications
You must be signed in to change notification settings - Fork 191
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
add shared library support #338
Conversation
8f9aa2e
to
f014077
Compare
i prefer not to release a binary with __wasm_call_ctors. |
f014077
to
f16150e
Compare
I've rebased onto main and removed the patch. @yamt does that address your concern regarding |
c8876db
to
e6e8ec4
Compare
e6e8ec4
to
fdd022f
Compare
no. |
wasi-sdk.cmake
Outdated
@@ -38,3 +38,5 @@ set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) | |||
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) | |||
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) | |||
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) | |||
|
|||
set(CMAKE_POSITION_INDEPENDENT_CODE On) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure how these cmake files are supposed to be used wrt shared library. can you explain a bit?
is it intended to always build pic even if shared lib is not used? why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I added CMAKE_POSITION_INDEPENDENT_CODE
to LIBCXX_CMAKE_FLAGS
in the Makefile, but it wasn't working (i.e. libc++.so and libc++abi.so still contained position-dependent code), so I added the lines to wasi-sdk.cmake and wasi-sdk-pthread.cmake. However, I just tried moving it back to Makefile, it that works fine now, so I'll push an update.
How does this plan sound to you?
|
Its possible you could get that patch backported to the 17 branch.. it seems very low risk.
|
More generally, I wonder if we should follow the Rust project's example and create a WebAssembly/llvm-project fork as a home for backports (cf. https://github.com/rust-lang/llvm-project). I do agree that backporting upstream is ideal whenever possible, but it would be nice to have a fallback option that doesn't involve applying patches at build time. |
Personally, I think the fact that we build wasi-sdk directly from upstream llvm is a really nice feature. It means the sdk is truly just a vanilla clang. Nothing more and nothing less. wasi-libc also supports a range of stable llvm releases which is really nice. Folks can take wasi-libc and use it with their own pre-built llvm binaries. If wasi-sdk started to diverge from vanilla llvm I think it could cause confusion and mean that such users would not have the same experience as wasi-sdk users. |
i tried to make a backport request, following https://www.llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches. |
FYI, I've opened WebAssembly/wasi-libc#440 to remove the |
I don't think I've tried to backport anything since the switch to github, but it seems unlikely that they wouldn't accept request from external folks. @yamt can you link to the issue you created and I can see if I can mark it correctly? |
llvm/llvm-project#68385 |
Looks like I was able to add the Milestone to llvm/llvm-project#68387 |
thank you |
@sbc100 In case you missed it, looks like this is waiting on confirmation from you: llvm/llvm-project-release-prs#773 (comment) |
I've updated both the |
Looks like the CI failure was due to a spurious network issue. Would someone who has the appropriate permissions please re-run the failed job? |
Can we do the llvm update as a separate PR maybe? |
Restarted failed CI jobs |
Ok, it seems to me that we just need to remove the LLVM submodule update from this PR (since it happened in #362) and then this should be good to go? |
This adds support for building WASI shared libraries per https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md. For the time being, the goal is to allow "pseudo-dynamic" linking using the Component Model per https://github.com/WebAssembly/component-model/blob/main/design/mvp/examples/SharedEverythingDynamicLinking.md. This requires all libraries to be available when the component is created, but still allows runtime symbol resolution via `dlopen`/`dlsym` backed by a static lookup table. This is sufficient to support Python native extensions, for example. A complete demo using `wit-component` is available at https://github.com/dicej/component-linking-demo. This requires https://reviews.llvm.org/D153293, which we will need to backport to LLVM 16 we're ready to upgrade to LLVM 17, hence the llvm-D153293-backport.patch file. Signed-off-by: Joel Dice <[email protected]>
This is where I originally meant the directive to go, but it didn't seem to work the first time I tried it, hence the added lines in wasi-sdk.cmake and wasi-sdk-pthread.cmake. However, it seems to work fine now, so I'm switching it back to be consistent with other similar CMake flags. Signed-off-by: Joel Dice <[email protected]>
Signed-off-by: Joel Dice <[email protected]>
b9743ab
to
3e0a45a
Compare
I just force-pushed a rebase onto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm now!
(If I had my druthers to wasm-libc updated would also land separately..)
Makefile
Outdated
$(MAKE) -C $(ROOT_DIR)/src/wasi-libc \ | ||
CC=$(BUILD_PREFIX)/bin/clang \ | ||
AR=$(BUILD_PREFIX)/bin/llvm-ar \ | ||
NM=$(BUILD_PREFIX)/bin/llvm-nm \ | ||
SYSROOT=$(BUILD_PREFIX)/share/wasi-sysroot \ | ||
BUILTINS_LIB=$(BUILD_PREFIX)/lib/clang/$(CLANG_VERSION)/lib/wasi/libclang_rt.builtins-wasm32.a \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is BUILTINS_LIB
now needed where it wasn't before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's needed for the libc.so link step to succeed, but it looks like WebAssembly/wasi-libc#442 has removed the need to specify it explicitly, so I'll remove it.
@@ -3,7 +3,7 @@ | |||
url = https://github.com/llvm/llvm-project | |||
[submodule "src/wasi-libc"] | |||
path = src/wasi-libc | |||
url = https://github.com/CraneStation/wasi-libc | |||
url = https://github.com/WebAssembly/wasi-libc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems unrelated.. but a good change.
As of WebAssembly/wasi-libc#442, these are determined automatically. Signed-off-by: Joel Dice <[email protected]>
This adds support for building WASI shared libraries per https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md.
For the time being, the goal is to allow "pseudo-dynamic" linking using the Component Model per
https://github.com/WebAssembly/component-model/blob/main/design/mvp/examples/SharedEverythingDynamicLinking.md. This requires all libraries to be available when the component is created, but still allows runtime symbol resolution via
dlopen
/dlsym
backed by a static lookup table. This is sufficient to support Python native extensions, for example. A complete demo usingwit-component
is available at https://github.com/dicej/component-linking-demo.This requires https://reviews.llvm.org/D153293, which we will need to backport to LLVM 16 until 17 is released, hence the llvm-D153293-backport.patch file.