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.

On Mon, Dec 18, 2023 at 10:53 AM Alon Zakai <alonza...@gmail.com> wrote:

> 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:
>
> https://github.com/emscripten-core/emscripten/pull/20802
>
>
>
> On Sat, Dec 16, 2023 at 4:30 AM キャロウ マーク <git...@callow.im> wrote:
>
>>
>>
>> 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
>>
>> --
>> 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-discuss+unsubscr...@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
>> <https://groups.google.com/d/msgid/emscripten-discuss/EA1C9222-7CAD-47E0-9CCD-5E2BE2464D52%40callow.im?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQrOooyjug0aj5a025%3D%2B1xoYKcjnBW7p5cFcFzFMBQjfA%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQrOooyjug0aj5a025%3D%2B1xoYKcjnBW7p5cFcFzFMBQjfA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_Wkkyu-nV4zFRqhMnjXtY3oPD9st4SK3YXxMLSV2XFZQ%40mail.gmail.com.

Reply via email to