Don't build MAIN_MODULE as RELOCATABLE #25522

sbc100 · 2025-10-08T00:48:27Z

This means we no longer link main modules with -pie. The main
advantage here is that main modules no longer require
runtime relocation code for symbols defined locally.

To show the benefits of this approach I build binaryan_wasm
with -sMAIN_MODULE=1 both before and after this change.

Before:

Wasm Size: 22.6M
__wasm_apply_data_relocs size: 123k

After:

Wasm Size: 16.6M
__wasm_apply_data_relocs size: 0 (no longer exists)

Since this is quite a major change, I've kept the -sRELOCATABLE
option available so folks that use this to get the old behaviour when
linking their main module. In order to tests this path too now run
all the @needs_dylink tests in test_core.py with and without
-sRELOCTABLE. Hopefully we can remove this configuration
completely at some point in the future.

Fixes: #12682

Also, add an assertion to dynCall. Split out from emscripten-core#25522.

sbc100 · 2025-10-22T20:25:24Z

I still need to get some stats on the benefits of this, but that tests are all now passing so I think this should be good to review now.

An open question is: What do we do about -sRELOCTABLE. Once this change lands we will have almost not testing on this flag. We do have plan to remove it: #25262. One option is to remove -sRELOCATABLE before this change lands?

Also, add an assertion to dynCall. Split out from emscripten-core#25522.

kripken · 2025-10-22T22:21:31Z

Yeah, I see what you mean, removing RELOCATABLE first would simplify this a little. I don't have a preference though.

I do see some tests still fail here though?

Also, add an assertion to dynCall. Split out from #25522.

tools/compile.py

ChangeLog.md

sbc100 · 2025-10-28T00:17:08Z

Ok, aside from the problem of what to do with -sRELOCATABLE setting, this change is not ready to go I think.

The stats look really promising. See the new PR description for the great improvements measured when building a dylink version of binaryen.

src/lib/libdylink.js

test/common.py

sbc100 · 2025-10-29T00:30:10Z

I solves the -sRELOCTABLE issue by keeping that available as an option and test that configuration too.

src/lib/libdylink.js

sbc100 · 2025-10-29T18:15:05Z

I think these change should be more of less ready to land now.

The old -sRELOCTABLE mode is still available for now.

Once I land this I will likely send a message to mailing list too since its a fairly large change for users of dynamic linking.

src/lib/libdylink.js

kripken · 2025-10-29T18:16:05Z

test/test_core.py

+    if relocatable:
+      # Since `-sMAIN_MODULE` no longer implies `-sRELOCATABLE` but we want
+      # to keep that cominbation working we run all the `@needs_dylink` tests
+      # both with and without the explicit `-sRELOCATABLE`


This is quite a lot of slow tests - is it worth it?

I think this is important as long as we want to offer people a fallback using -sRELOCATABLE for some period of time, which I do think is good idea.

Once we remove the fallback option we can then remove all these tests.

How much time does it take? I just vaguely worry dylink tests are most of our core time, and doubling them would almost double the total...

These two tests total 61 out of 1176 total core2 tests.

In terms of runtime of the core2 test suite they comprise 9 seconds of the full runtime of 63 seconds (I skipped the slow tests there too).

Ok, sg, thanks for checking.

kripken

lgtm % comments now and before

test/test_other.py

tools/emscripten.py

The main advantage here is that main module no longer requires relocation entries for symbols defined locally. To show the benefits of this approach I build binaryan_wasm with `-sMAIN_MODULE=1` both before and after this change. Before: Wasm Size: 22.6M __wasm_apply_data_relocs size: 123k After: Wasm Size: 16.6M __wasm_apply_data_relocs size: 0 (no longer exists) Fixes: emscripten-core#12682

This issue was introduces in emscripten-core#25522 when `-sRELOCATABLE` was removed from `get_base_cflags. This is a somewhat tricky to reproduce / understand issue with transitive library building: 1. User attempts to compile program using SDL2 + SDL2_GFX. 2. `emcc` attempts to builds all needed libraries in reverse dependency order. And ends up with the follows sequence: 1. libsdl2-pic 2. libsdl2_gfx-pic 3. `emcc` builds libsdl2-pic 4. `emcc` builds libsdl2_gfx-pic. The command that it constructs when building each source file looks like `emcc -fPIC gfx.c -sUSE_SDL=2`. However because neither `-sMAIN_MODULE` nor `-sRELOCATABLE` were specified this `emcc` command will not try to build the non-PIC version of libsdl2. At this point the compiler will crash with: `AssertionError: attempt to lock the cache while a parent process is holding the lock (sysroot/lib/wasm32-emscripten/libSDL2.a)` This issue is hard to reproduce because if libsdl2 is already built it will not trigger the issue.

This issue was introduces in #25522 when `-sRELOCATABLE` was removed from `get_base_cflags. This is a somewhat tricky to reproduce / understand issue with transitive library building: 1. User attempts to compile program using SDL2 + SDL2_GFX. 2. `emcc` attempts to builds all needed libraries in reverse dependency order. And ends up with the follows sequence: 1. libsdl2-pic 2. libsdl2_gfx-pic 3. `emcc` builds libsdl2-pic 4. `emcc` builds libsdl2_gfx-pic. The command that it constructs when building each source file looks like `emcc -fPIC gfx.c -sUSE_SDL=2`. However because neither `-sMAIN_MODULE` nor `-sRELOCATABLE` were specified this `emcc` command will not try to build the non-PIC version of libsdl2. At this point the compiler will crash with: `AssertionError: attempt to lock the cache while a parent process is holding the lock (sysroot/lib/wasm32-emscripten/libSDL2.a)` This issue is hard to reproduce because if libsdl2 is already built it will not trigger the issue.

sbc100 mentioned this pull request Oct 9, 2025

WASM binary size with -sMAIN_MODULE 7 to 9 times heavier #25482

Open

sbc100 force-pushed the main_module_static_v2 branch 2 times, most recently from cd1b8ce to e8f95c7 Compare October 22, 2025 19:23

sbc100 added a commit to sbc100/emscripten that referenced this pull request Oct 22, 2025

Use createNamedFunction for asyncify wrappers. NFC

3191c55

Also, add an assertion to dynCall. Split out from emscripten-core#25522.

sbc100 added a commit to sbc100/emscripten that referenced this pull request Oct 22, 2025

Use createNamedFunction for asyncify wrappers. NFC

72422d0

Also, add an assertion to dynCall. Split out from emscripten-core#25522.

sbc100 mentioned this pull request Oct 22, 2025

Use createNamedFunction for asyncify wrappers. NFC #25623

Merged

sbc100 force-pushed the main_module_static_v2 branch 2 times, most recently from 8c32591 to d40087a Compare October 22, 2025 20:17

sbc100 requested review from dschuff and kripken October 22, 2025 20:22

sbc100 added a commit to sbc100/emscripten that referenced this pull request Oct 22, 2025

Use createNamedFunction for asyncify wrappers. NFC

2a283d1

Also, add an assertion to dynCall. Split out from emscripten-core#25522.

sbc100 force-pushed the main_module_static_v2 branch from d40087a to 6008112 Compare October 22, 2025 20:49

sbc100 added a commit that referenced this pull request Oct 22, 2025

Use createNamedFunction for asyncify wrappers. NFC (#25623)

8462d7a

Also, add an assertion to dynCall. Split out from #25522.

sbc100 force-pushed the main_module_static_v2 branch 5 times, most recently from 637ed91 to f56f631 Compare October 24, 2025 21:07

kleisauke reviewed Oct 25, 2025

View reviewed changes

tools/compile.py Show resolved Hide resolved

mho22 mentioned this pull request Oct 25, 2025

[ php-wasm ] Add intl dynamic extension to @php-wasm/web WordPress/wordpress-playground#2591

Draft

10 tasks

kleisauke reviewed Oct 27, 2025

View reviewed changes

ChangeLog.md Outdated Show resolved Hide resolved

sbc100 force-pushed the main_module_static_v2 branch 2 times, most recently from 0294236 to d499627 Compare October 28, 2025 00:15

sbc100 force-pushed the main_module_static_v2 branch from d499627 to 2c6de78 Compare October 28, 2025 00:59

kripken reviewed Oct 28, 2025

View reviewed changes

src/lib/libdylink.js Outdated Show resolved Hide resolved

src/lib/libdylink.js Show resolved Hide resolved

test/common.py Show resolved Hide resolved

sbc100 force-pushed the main_module_static_v2 branch 2 times, most recently from 23d619c to a2e97ec Compare October 28, 2025 23:57

sbc100 force-pushed the main_module_static_v2 branch from a2e97ec to 4425035 Compare October 29, 2025 00:27

sbc100 requested a review from kleisauke October 29, 2025 00:29

kripken reviewed Oct 29, 2025

View reviewed changes

src/lib/libdylink.js Outdated Show resolved Hide resolved

src/lib/libdylink.js Outdated Show resolved Hide resolved

src/lib/libdylink.js Show resolved Hide resolved

sbc100 force-pushed the main_module_static_v2 branch 2 times, most recently from c7635d5 to a2a8c13 Compare October 29, 2025 16:31

sbc100 requested a review from kripken October 29, 2025 18:00

sbc100 force-pushed the main_module_static_v2 branch from a2a8c13 to 79e885d Compare October 29, 2025 18:11

kripken reviewed Oct 29, 2025

View reviewed changes

kripken approved these changes Oct 29, 2025

View reviewed changes

test/test_other.py Show resolved Hide resolved

tools/emscripten.py Show resolved Hide resolved

sbc100 force-pushed the main_module_static_v2 branch from 5bbdf80 to 0cdfabc Compare October 29, 2025 18:21

sbc100 force-pushed the main_module_static_v2 branch from 0cdfabc to 55ea688 Compare October 29, 2025 18:30

sbc100 enabled auto-merge (squash) October 29, 2025 18:36

sbc100 merged commit 4d16f75 into emscripten-core:main Oct 29, 2025
34 checks passed

sbc100 deleted the main_module_static_v2 branch October 29, 2025 19:58

sbc100 mentioned this pull request Nov 3, 2025

Fix issue with transitive/recursive building of PIC libraries #25707

Merged

Don't build MAIN_MODULE as RELOCATABLE #25522

Don't build MAIN_MODULE as RELOCATABLE #25522

Uh oh!

Conversation

sbc100 commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbc100 commented Oct 22, 2025

Uh oh!

kripken commented Oct 22, 2025

Uh oh!

Uh oh!

Uh oh!

sbc100 commented Oct 28, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sbc100 commented Oct 29, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sbc100 commented Oct 29, 2025

Uh oh!

Uh oh!

kripken Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

kripken Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

kripken Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

kripken left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sbc100 commented Oct 8, 2025 •

edited

Loading