matplotlib breaks in v0.24.0

[WebReflection]

🐛 Bug

In an attempt to update polyscript to this latest version of Pyodide, I've smoke-tested our long working matplotlib example and saw this on screen:

To Reproduce

• grab polyscript
• enter the folder then checkout pyodide-update branch
• npm i followed by npm run build and finally npm run server
• visit the localhost url and try any matplot example you like (they are all the same)
• see the error ... fee free to change the version via absolute URL or local file in here as version="http://localhost..." then refresh for better debugging
• feel free to use NO_MIN npm run build if you think something is wrong to the library (although the same example works by using previous version)

Expected behavior

A page with an image once everything is done ... I just see a lot of errors instead with 0.24

Environment

• Pyodide Version: 0.24.0
• Browser version: latest Chrome
• Any other relevant information: I can create a plain example if needed ... just let me know

Additional context

[bugzpodder]

@WebReflection matplotlib works fine when loaded directly. see this example:
https://pyscript.com/@bugzpodder/pyodide-matplotlib/latest

I have not tested polyscript.

Also packages in loadPyodide calls loadPackages which is different from micropip.install. one difference is some will throw an exception when you provide it to packages in loadPyodide, eg seaborn

[bugzpodder]

the error you see is caused by triang = tri.Triangulation(x, y) in your code
see https://pyscript.com/@bugzpodder/pyodide-matplotlib-copy/latest

import matplotlib.tri as tri
tri.Triangulation([-5.78687373, -4.58366236, -3.95340879], [49.96191974, 50.59217331, 50.87865221])

[WebReflection]

@bugzpodder so the issue is that 0.24.0 uses a new version of matplotlib that in turns fails with the previous code? I think that's still unexpected for users as there was no deprecation warning to date and that code works just fine with 0.23.4 but thanks for investigating this!

[rth]

No so the version of matplotlib is still 3.5.2 in both releases. I can confirm that it's a regression in v0.24.0. Thanks for the minimal example @bugzpodder !

Most likely due to the Emscripten update. As far as I understand that symbol should be defined there and enabled by default.

1: Default support, depending on the exception mode. wasm if -fwasm-exception is used, emscripten otherwise.

I have a feeling it's due to emscripten-core/emscripten#19004 so we may need to set SUPPORT_LONGJMP=wasm though I'm not sure if we can have that without enabling exception handling (so it may need #3817 which will only be included in the next release).

[ryanking13]

Hmm, this is strange... we didn't enable wasm-exception in the Pyodide main branch so it is not clear why the symbol mismatches

[hoodmane]

I thought we had a test for setjmp/longjmp but apparently we don't, only cpp-exceptions-test.

[hoodmane]

wait actually we do have one, set_jmp_func in cpp-exceptions-test. Strange.

[hoodmane]

There seems to be a problem caused by -flto -fno-lto.

[hoodmane]

Opened an upstream bug report:
emscripten-core/emscripten#20308