Default wasm32-wasip2 objects to -fPIC by default
#495
Conversation
This commit updates all of the `*.a` archives built for the `wasm32-wasip2` target to use `-fPIC` instead of the default non-PIC flag. This makes them suitable for linking into either a dynamic library or a non-dynamic binary without recompiling libc. This is intended to help integrate shared libraries into other precompiled languages, such as Rust's standard library, as it makes its way upstream. Lots of discussion about this also happened on WebAssembly#429 so I wanted to highlight that this is only happening for the wasm32-wasip2 target and no other targets. For example neither wasm32-wasi nor wasm32-wasip1 are affected. Only users of wasm32-wasip2, of which there aren't too too many, are possibly affected by the runtime overheads here. I have not measured the hypothetical runtime myself, however.
|
This is intended to eventually accompany rust-lang/rust#124858 on the Rust side of things. |
|
But for |
|
Thinking more on this, that's a good point @TerrorJack. I blindly did this to align with what I was changing the Rust target to do but while it's appropriate in Rust there's no need here in C. The Rust target is changing the default for objects on wasm32-wasip2 to ensure that the precompiled standard library can be used with shared objects but it's not required to. If a shared object is being created though then libc.so will have to come from somewhere and it'll probably be an external Given that I don't think that this is actually necessary, so I'll close this. |
This commit updates all of the
*.aarchives built for thewasm32-wasip2target to use-fPICinstead of the default non-PIC flag. This makes them suitable for linking into either a dynamic library or a non-dynamic binary without recompiling libc. This is intended to help integrate shared libraries into other precompiled languages, such as Rust's standard library, as it makes its way upstream.Lots of discussion about this also happened on #429 so I wanted to highlight that this is only happening for the wasm32-wasip2 target and no other targets. For example neither wasm32-wasi nor wasm32-wasip1 are affected. Only users of wasm32-wasip2, of which there aren't too too many, are possibly affected by the runtime overheads here. I have not measured the hypothetical runtime myself, however.