[dylink] Normalize library paths to prevent duplicate loading by pepijndevos · Pull Request #26399 · emscripten-core/emscripten

pepijndevos · 2026-03-06T07:41:10Z

Summary

When a shared library in a subdirectory references a dependency via $ORIGIN/.. rpath, findLibraryFS resolves it to a non-canonical path containing .. (e.g. sub/../lib.so). Since loadDynamicLibrary uses the raw path as the LDSO.loadedLibsByName key, this causes the same library to be loaded twice under different names, running __wasm_call_ctors twice.

This was discovered while building KLayout for Pyodide. KLayout has plugins in a db_plugins/ subdirectory that depend on shared libraries in the parent directory via -Wl,-rpath,$ORIGIN/... The rpath gets embedded in the dylink.0 RUNTIME_PATH section. When Pyodide loads the plugins, findLibraryFS resolves the dependency to e.g. /lib/.../db_plugins/../lib_gsi.so, which doesn't match the already-loaded /lib/.../lib_gsi.so in LDSO.

Note that dlopenInternal already calls PATH.normalize(filename) before calling loadDynamicLibrary. However, nested dependencies loaded via the neededDynlibs reduce chain bypass dlopenInternal and call loadDynamicLibrary directly with the non-canonical path from findLibraryFS.

Fix

Add libName = PATH.normalize(libName) at the top of loadDynamicLibrary, matching what dlopenInternal already does.

When a shared library in a subdirectory references a dependency via $ORIGIN/.. rpath, findLibraryFS resolves it to a non-canonical path (e.g. "sub/../lib.so"). Since loadDynamicLibrary uses the raw path as the LDSO key, this causes the same library to be loaded twice. This complements patch 0003 which added findLibraryFS for nested dependency resolution but didn't normalize the resolved paths. Upstream: emscripten-core/emscripten#26399 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/lib/libdylink.js

hoodmane · 2026-03-06T09:12:18Z

Can you add a test @pepijndevos?

When a shared library in a subdirectory references a dependency via $ORIGIN/.. rpath, findLibraryFS resolves it to a non-canonical path containing ".." (e.g. "sub/../lib.so"). Since loadDynamicLibrary uses the raw path as the LDSO key, this causes the same library to be loaded twice under different names, running constructors twice. Fix by normalizing libName with PATH.normalize() at the top of loadDynamicLibrary, matching what dlopenInternal already does. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

pepijndevos · 2026-03-06T12:27:22Z

I have made an attempt 🫣

hoodmane · 2026-03-06T13:10:44Z

test/test_other.py

+      printf("base: %d\n", base_func());
+      printf("plugin: %d\n", plugin_func());
+      printf("init_count: %d\n", get_init_count());


Can we use assert(base_func() == 42) etc here? I think that's easier to understand than matching the output agaisnt base: 42\nplugin: 43\ninit_count: 1\n.

You can print success at end and match on that.

sbc100 · 2026-03-06T18:08:48Z

Can we now remove from PATH.normalize from dlopenInternal then since its redundant now?

sbc100 · 2026-03-06T18:18:09Z

test/test_other.py

+    create_file('libbase.cpp', r'''
+    #include <stdio.h>
+    static int init_count = 0;
+    struct Init { Init() { init_count++; } };


Can you make this a C file using __attribute__((constructor)) instead

sbc100 · 2026-03-06T18:19:25Z

test/test_other.py

+    self.run_process([EMCC, '-o', 'libbase.so', 'libbase.cpp', '-sSIDE_MODULE'])
+    self.run_process([EMCC, '-o', 'subdir/libplugin.so', 'libplugin.c', '-sSIDE_MODULE', './libbase.so', '-Wl,-rpath,$ORIGIN/..'])
+    self.do_runf('main.c', 'base: 42\nplugin: 43\ninit_count: 1\n',
+                 cflags=['--profiling-funcs', '-sMAIN_MODULE=2', '-sINITIAL_MEMORY=32Mb',


Is -sINITIAL_MEMORY=32Mb needed here?

sbc100

lgtm % comments.

Thanks for working on this!

- Convert test library from C++ to C using __attribute__((constructor)) - Use assert() checks instead of printf output matching - Remove unnecessary -sINITIAL_MEMORY=32Mb flag - Remove redundant PATH.normalize() from dlopenInternal Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

sbc100

Thanks!

pepijndevos · 2026-03-09T05:50:48Z

Did the code size check prevent auto merge?

hoodmane · 2026-03-09T08:31:20Z

Yup.

sbc100 · 2026-03-09T15:39:18Z

Apologies. Code size test are often in flux. I just landed an auto-update to the code size test this minute, for example.

Can you run emsdk install tot to make sure you have the very latest binaries and then run ./tools/maint/rebaseline_tests.py. This should be a no-op on the main branch and perhaps produce some changed in your branch (at least one I imagine).

sbc100 · 2026-03-09T15:40:09Z

If you are having trouble getting the codesize test results to match I can make a commit to this PR, but please try to it yourself first.

This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (9) test expectation files were updated by running the tests with `--rebaseline`: ``` codesize/test_codesize_cxx_ctors1.json: 152368 => 152420 [+52 bytes / +0.03%] codesize/test_codesize_cxx_ctors2.json: 151765 => 151817 [+52 bytes / +0.03%] codesize/test_codesize_cxx_lto.json: 120968 => 121028 [+60 bytes / +0.05%] codesize/test_codesize_cxx_noexcept.json: 154375 => 154427 [+52 bytes / +0.03%] codesize/test_codesize_cxx_wasmfs.json: 179944 => 179996 [+52 bytes / +0.03%] codesize/test_codesize_hello_dylink.json: 44326 => 44334 [+8 bytes / +0.02%] codesize/test_codesize_hello_dylink_all.json: 822383 => 822379 [-4 bytes / -0.00%] codesize/test_minimal_runtime_code_size_hello_embind.json: 14891 => 14908 [+17 bytes / +0.11%] codesize/test_minimal_runtime_code_size_hello_embind_val.json: 11687 => 11703 [+16 bytes / +0.14%] Average change: +0.05% (-0.00% - +0.14%) ```

pepijndevos · 2026-03-10T14:57:17Z

Well that was fun now everything conflicts 🙈 I could rebase and do it again but uh that seems like the kind of system best touched by a contributor who can merge it before it gets out of date.

sbc100 · 2026-03-10T15:18:21Z

Well that was fun now everything conflicts 🙈 I could rebase and do it again but uh that seems like the kind of system best touched by a contributor who can merge it before it gets out of date.

Sorry yes these file to tend to change often.

I just revert + rebase + ./tools/maint/rebaseline_tests.py each time it happens.

pepijndevos mentioned this pull request Mar 6, 2026

Add emsdk patch to normalize library paths in loadDynamicLibrary pyodide/pyodide#6121

Merged

hoodmane reviewed Mar 6, 2026

View reviewed changes

src/lib/libdylink.js Show resolved Hide resolved

pepijndevos force-pushed the fix/dylink-normalize-paths branch from 6a15c59 to 0661a9e Compare March 6, 2026 08:55

pepijndevos force-pushed the fix/dylink-normalize-paths branch from 0661a9e to 894496e Compare March 6, 2026 12:16

hoodmane reviewed Mar 6, 2026

View reviewed changes

sbc100 reviewed Mar 6, 2026

View reviewed changes

sbc100 approved these changes Mar 6, 2026

View reviewed changes

sbc100 enabled auto-merge (squash) March 6, 2026 19:46

sbc100 added the ai-assisted label Mar 6, 2026

auto-merge was automatically disabled March 10, 2026 14:56
Head branch was pushed to by a user without write access

Conversation

pepijndevos commented Mar 6, 2026

Summary

Fix

Related

Uh oh!

Uh oh!

hoodmane commented Mar 6, 2026

Uh oh!

pepijndevos commented Mar 6, 2026

Uh oh!

hoodmane Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

hoodmane Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Mar 6, 2026

Uh oh!

sbc100 Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

sbc100 Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

pepijndevos commented Mar 9, 2026

Uh oh!

hoodmane commented Mar 9, 2026

Uh oh!

sbc100 commented Mar 9, 2026

Uh oh!

sbc100 commented Mar 9, 2026

Uh oh!

pepijndevos commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbc100 commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pepijndevos commented Mar 10, 2026 •

edited

Loading