emscripten_GetProcAddress undefined

32 views
Skip to first unread message

キャロウ マーク

unread,
Dec 15, 2023, 5:45:38 AM12/15/23
to emscripte...@googlegroups.com
My CI builds have suddenly started failing with wasm_ld reporting emscripten_GetProcAddress undefined errors. It is reporting one error for each call to the function rather than one overall. I have not changed anything in my code so I think this must be related to an update to the Emscripten Docker image. My builds use emscripten/emsdk:latest. It is emcc 3.1.51 with clang 18.0.0git. It seems unlikely this is a bug. Has there been a change that I need to accommodate my code to?

Regards

-Mark
signature.asc

キャロウ マーク

unread,
Dec 16, 2023, 7:30:35 AM12/16/23
to emscripten-discuss Sam Clegg via

On Dec 15, 2023, at 19:45, キャロウ マーク <git...@callow.im> wrote:

My CI builds have suddenly started failing with wasm_ld reporting emscripten_GetProcAddress undefined errors. It is reporting one error for each call to the function rather than one overall. I have not changed anything in my code so I think this must be related to an update to the Emscripten Docker image. My builds use emscripten/emsdk:latest. It is emcc 3.1.51 with clang 18.0.0git. It seems unlikely this is a bug. Has there been a change that I need to accommodate my code to?

I found the breaking change in the changelog:

Breaking change: Using the *glGetProcAddress() family of functions now requires passing a linker flag -sGL_ENABLE_GET_PROC_ADDRESS. This prevents ports of native GL renderers from later accidentally attempting to activate "dormant" features if web browser implementations gain new WebGL extensions in the future, which *glGetProcAddress() is not able to support. (#20802)

I do not understand the reason given for the change. As far as I understand it the issue is that Emscripten reveals all the extensions offered by the WebGL implementation even if they are not implemented by Emscripten’s {GL,ES} wrapper and thus has no address for glGetProcAddress to return. If this is a correct understanding, the issue should be fixed by Emscripten filtering the extension list so it only shows those its wrappers implement not by introducing breaking changes. I think the majority of GL applications use GetProcAddress.

Regards

    -Mark

signature.asc

Alon Zakai

unread,
Dec 18, 2023, 1:53:24 PM12/18/23
to emscripte...@googlegroups.com
I don't know enough to answer that question, but I suggest asking it on the PR, as the authors might not see things here on the mailing list, but will definitely see it there:




--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/EA1C9222-7CAD-47E0-9CCD-5E2BE2464D52%40callow.im.

Sam Clegg

unread,
Dec 18, 2023, 2:27:45 PM12/18/23
to emscripte...@googlegroups.com
IIRC the logic for remove this support by default is layed out in the PR description for https://github.com/emscripten-core/emscripten/pull/20802.

;TLDR; Since some 6 years apo, our best practices document has advocated users against using *glGetProcAddress() functions when targeting the web: https://emscripten.org/docs/optimizing/Optimizing-WebGL.html#optimizing-load-times-and-other-best-practices , due to the massive code size bloat that it causes (but also due to the performance problems that using it brings). Users are advised to not use that function.

Reply all
Reply to author
Forward
0 new messages