wasm built with SIDE_MODULE allows undefined symbols #18198
Assignees
Labels
Comments
|
This is a little tricky but I think we can probably make it work. The reason its tricky is that, with emscripten, all the system libraries are linked into the main module rather than being their own shared libraries (e.g. we don't have a libc.so). |
sbc100
added a commit
to sbc100/emscripten
that referenced
this issue
Nov 28, 2023
This is currently the default for shared libraries and PIC executables in the linker but I'm hoping to change that soon. This change means emscripten will not get broken if/when that happens. See emscripten-core#18198
br0nk
pushed a commit
to br0nk/emscripten
that referenced
this issue
Nov 29, 2023
…emscripten-core#20795) This is currently the default for shared libraries and PIC executables in the linker but I'm hoping to change that soon. This change means emscripten will not get broken if/when that happens. See emscripten-core#18198
sbc100
added a commit
to llvm/llvm-project
that referenced
this issue
Dec 20, 2023
The current (experimental) spec for WebAssembly shared libraries does not include a full symbol table like the object format. This change extracts symbol information from the normal wasm exports. This is the first step in having the linker report undefined symbols when linking with shared libraries. The current behaviour is to ignore all undefined symbols when linking with `-pie` or `-shared`. See emscripten-core/emscripten#18198
sbc100
added a commit
to sbc100/llvm-project
that referenced
this issue
Dec 20, 2023
…uilds Previously we would ignore/import all undefined symbols when using `-shared` or `-pie`. With this change we now track symbol in shared libraries and report undefined symbols by default. This can be a breaking change for any users of dyanmic linking. However, the old behaviour is still available using `--unresolved-symbols=import-dynamic`. This rationale for allowing this type of breaking change is that `-pie` and `-shared` are both still experimental will warn as such, unless `--experimental-pic` is passed. See emscripten-core/emscripten#18198
|
I have made some significant progress on this on the llvm side but it now quite there yet. |
qihangkong
pushed a commit
to rvgpu/rvgpu-llvm
that referenced
this issue
Apr 23, 2024
The current (experimental) spec for WebAssembly shared libraries does not include a full symbol table like the object format. This change extracts symbol information from the normal wasm exports. This is the first step in having the linker report undefined symbols when linking with shared libraries. The current behaviour is to ignore all undefined symbols when linking with `-pie` or `-shared`. See emscripten-core/emscripten#18198
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When building a side module ( for run time or load dynamically linking), it looks undefined symbols in the side module are not reported when building the side module (at linking phase), and undefined symbols are reported when it’s finally linked (load time linking) with main module. This behaviour is different from Native Dynamic Linking (say on osx .framework or linux .so) where an executable should have all the symbols either resolved or weakly linked at build time.
We want have same behaviour as on native platforms so that undefined symbols are reported at build time of that side module rather than quite later at final linking with main module. How can it be achieved?
The text was updated successfully, but these errors were encountered: