emscripten
emscripten copied to clipboard
[dylink] Fix rpath calculation in nested dependencies
This fixes a bug in rpath calculation in nested dependencies.
Basically, it fixes a case when a relative path is passed to the loadDynamicLibrary.
Think of the following scenario:
- libhello.wasm depends on libhello_dep.so depends on libhello_nested_dep.so
- [main.c] calls dlopen('/usr/lib/libhello.wasm')
- [dynlink.c] calls
loadDynamicLibrary('/usr/lib/libhello.wasm')(_dlopen_js ==> dlopenInternal ==> loadDynamicLibrary) - [libdylink.js] inside
loadDynamicLibrary('/usr/lib/libhello.wasm'), it loads the dependencylibhello_dep.so. When locatinglibhello_dep.so, it usesparentLibPath: /usr/lib/libhello.wasmit locates the library correctly from/usr/lib/libhello_dep.so. - [libdylink.js] Now we call
loadDynamicLibrary('libhello_dep.so'), and it loads its dependency 'libhello_nested_dep.so' first. In this case it usesparentLibPath: libhello_dep.soso it fails to locate the library.
@sbc100, May I ask for your review again when you have time?
@ryanking13 I'm curious about the different between this patch and #25694. Do they both solve the same issue? Do you have a preference for one over the other?
Also, could you rebase (or merge) this ?
@ryanking13 I'm curious about the different between this patch and https://github.com/emscripten-core/emscripten/pull/25694. Do they both solve the same issue? Do you have a preference for one over the other?
@sbc100 Thanks for the review!
I think both approaches somehow solve this nested dependency issue, but I prefer mine because I think this is more straightforward. https://github.com/emscripten-core/emscripten/pull/25694 modifies the libName variable in multiple places which increases the cognitive load. This PR always resolves the libname before running loadDynamicLibrary soi I think it is better.
@sbc100
Would this also fix https://github.com/emscripten-core/emscripten/issues/25814?
Unfortunately no, I tested the worker case but I get fiile not found error. Does --embed-file parameter work differently in worker?
To get the codesize expectations to match you need to run toosl/main/rebaseline_test.py after first doing emsdk install tot. If you have having trouble doing that let me know and I can push the expected results.
@sbc100
To get the codesize expectations to match you need to run toosl/main/rebaseline_test.py after first doing emsdk install tot. If you have having trouble doing that let me know and I can push the expected results.
Thanks, updated the codesize. I think where was some code courrupted in my cache.