Always build wasm32-wasip2 with -fPIC
#564
Conversation
This commit updates the build of the `wasm32-wasip2` target to always pass `-fPIC` to compilation of wasi-libc. This notably enables using `libc.a` in dynamic linking situations instead of being forced to use `libc.so`. While many applications likely want to use `libc.so` I've found it more flexible if objects are compatible with as many builds as possible. This will enable, for example, building shared libraries in Rust by default since Rust only ships `libc.a`, not `libc.so`, in the pre-built sysroot. This behavior additionally matches the Rust `wasm32-wasip2` target where `-fPIC` is enabled by default there.
There was a problem hiding this comment.
This updates wasi-libc to pull in WebAssembly/wasi-libc#624
There was a problem hiding this comment.
I went ahead and refactored this a bit to reduce the duplication between the various branches to also pass -fPIC unconditionally on wasip2
|
Blocked on WebAssembly/wasi-libc#625 for tests |
| elseif(${target} MATCHES p2) | ||
| list(APPEND extra_make_flags WASI_SNAPSHOT=p2) | ||
| # Always enable `-fPIC` for the `wasm32-wasip2` target. This makes `libc.a` | ||
| # more flexible and usable in dynamic linking situations. |
There was a problem hiding this comment.
why do you want to make p1 and p2 different in this regard?
is there any p2-specific motivations to use pic?
There was a problem hiding this comment.
We're using dynamic libraries in p2 for various languages and it's much easier if everything is -fPIC by default than trying to align the right toolchain flags and binaries. The consequence of this is that there's slight overhead in what the linker generates if you don't end up using a dynamic library, which is also quite common. This slight overhead has led to pushback in the past, so we changed the Rust target, for example, to avoid altering anything about a preexisting target.
Short answer: changing only one target makes this I think less controversial. The p2-specific reason is intended use cases and usage scenarios, but it's not a strong argument.
There was a problem hiding this comment.
certain OSes (eg. netbsd) ship pic versions of static libraries for similar purposes. i feel it's a better approach.
-r--r--r-- 1 root wheel 4123868 Mar 28 2024 /usr/lib/libc.a
-r--r--r-- 1 root wheel 9657674 Jul 17 2018 /usr/lib/libc_pic.a
There was a problem hiding this comment.
Can you detail why that's a better approach? That still suffers from "align the correct matrix of flags and objects" I'm trying to avoid.
This commit updates the build of the
wasm32-wasip2target to always pass-fPICto compilation of wasi-libc. This notably enables usinglibc.ain dynamic linking situations instead of being forced to uselibc.so. While many applications likely want to uselibc.soI've found it more flexible if objects are compatible with as many builds as possible. This will enable, for example, building shared libraries in Rust by default since Rust only shipslibc.a, notlibc.so, in the pre-built sysroot. This behavior additionally matches the Rustwasm32-wasip2target where-fPICis enabled by default there.