Skip to content

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Sep 30, 2025

This change remove some special casing in addFromLibrary which
simplifies the code, and also lays the groundwork for #25441 which
explicitly allows JS symbol to alias native ones.

This special handling was added in #19046 in order to deal with case
where glXXX symbols were simultaneously aliased by emscripten_glXX
and exported (in the case of MAIN_MODULE=1).

However, this work is no longer needed since in #21785 we stopped
stopped included symbol exported due to MAIN_MODULE=1 as part of
WASM_EXPORTS (the symbols are only exported to side modules, not to
JS).

In original problem was that emscripten_glXX should always points to
the original JS implementation, even if a native version is exported.
Just in case somebody is explicitly exporting these symbols this change
also flips the aliases such that the glXX functions are now aliases of
emscripten_glXX and not the other way around. This means that
exporting glXXX will replace/override the alias, but will not effect
emscripten_glXX.

@sbc100 sbc100 requested a review from kripken October 2, 2025 19:59
sbc100 added a commit to sbc100/emscripten that referenced this pull request Oct 2, 2025
This change remove some special casing in `addFromLibrary` which
simplifies the code, and also lays the groundwork for emscripten-core#25441 which
explicitly allows JS symbol to alias native ones.

This special handling was added in emscripten-core#19046 in order to deal with case
where `glXXX` symbols were simultaneously aliased by `emscripten_glXX`
and exported (in the case of MAIN_MODULE=1).

However, this work is no longer needed since in emscripten-core#21785 we stopped
stopped included symbol exported due to `MAIN_MODULE=1` as part of
WASM_EXPORT (the symbols are only exported to side modules, not to
JS).

In original problem was that `emscripten_glXX` should always points to
the original JS implementation, even if a native version is exported.
Just in case somebody is explicitly exporting these symbols this change
also flips the aliases such that the `glXX` functions are now aliases of
`emscripten_glXX` and not the other way around.  This means that
exporting `glXXX` will replace/override the alias, but will not effect
`emscripten_glXX`.
@sbc100 sbc100 force-pushed the remove_force_jslib branch from e9af1c3 to bf52815 Compare October 2, 2025 20:00
@sbc100 sbc100 changed the title Remove forcing of JS library aliases [js-compiler] Remove special handling for JS library aliases. NFC Oct 2, 2025
@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 2, 2025

Sorry for the long explanation, its quite a simple fix for a rather complex problem.

//
// We do this by renaming `glX` symbols to `emscripten_glX` and then setting
// `glX` as an alias of `emscripten_glX`. The reason for this renaming is to
// ensure that `emscripten_glX` is always available, even in cases were native
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// ensure that `emscripten_glX` is always available, even in cases were native
// ensure that `emscripten_glX` is always available, even in cases where native

@sbc100 sbc100 force-pushed the remove_force_jslib branch from bf52815 to 7e07047 Compare October 2, 2025 21:25
sbc100 added a commit to sbc100/emscripten that referenced this pull request Oct 2, 2025
This change remove some special casing in `addFromLibrary` which
simplifies the code, and also lays the groundwork for emscripten-core#25441 which
explicitly allows JS symbol to alias native ones.

This special handling was added in emscripten-core#19046 in order to deal with case
where `glXXX` symbols were simultaneously aliased by `emscripten_glXX`
and exported (in the case of MAIN_MODULE=1).

However, this work is no longer needed since in emscripten-core#21785 we stopped
stopped included symbol exported due to `MAIN_MODULE=1` as part of
WASM_EXPORT (the symbols are only exported to side modules, not to
JS).

In original problem was that `emscripten_glXX` should always points to
the original JS implementation, even if a native version is exported.
Just in case somebody is explicitly exporting these symbols this change
also flips the aliases such that the `glXX` functions are now aliases of
`emscripten_glXX` and not the other way around.  This means that
exporting `glXXX` will replace/override the alias, but will not effect
`emscripten_glXX`.
This change remove some special casing in `addFromLibrary` which
simplifies the code, and also lays the groundwork for emscripten-core#25441 which
explicitly allows JS symbol to alias native ones.

This special handling was added in emscripten-core#19046 in order to deal with case
where `glXXX` symbols were simultaneously aliased by `emscripten_glXX`
and exported (in the case of MAIN_MODULE=1).

However, this work is no longer needed since in emscripten-core#21785 we stopped
stopped included symbol exported due to `MAIN_MODULE=1` as part of
WASM_EXPORT (the symbols are only exported to side modules, not to
JS).

In original problem was that `emscripten_glXX` should always points to
the original JS implementation, even if a native version is exported.
Just in case somebody is explicitly exporting these symbols this change
also flips the aliases such that the `glXX` functions are now aliases of
`emscripten_glXX` and not the other way around.  This means that
exporting `glXXX` will replace/override the alias, but will not effect
`emscripten_glXX`.
@sbc100 sbc100 force-pushed the remove_force_jslib branch from 7e07047 to 3900dfd Compare October 2, 2025 21:32
@sbc100 sbc100 enabled auto-merge (squash) October 2, 2025 22:36
@sbc100 sbc100 merged commit d21ef58 into emscripten-core:main Oct 2, 2025
33 checks passed
@sbc100 sbc100 deleted the remove_force_jslib branch October 2, 2025 22:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants