Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preliminary support for geospatial stack #214

Merged
merged 12 commits into from
May 16, 2023
Merged

Preliminary support for geospatial stack #214

merged 12 commits into from
May 16, 2023

Conversation

lionel-
Copy link
Member

@lionel- lionel- commented May 12, 2023

  • Add recipes for sqlite3, proj, and gdal
  • Enable C++ exceptions. This uses an experimental wasm feature to avoid the overhead of emscripten emulation.
  • Reorganise build variables so that all projects use the same flags. The flags are exported and no longer need to be forwarded manually.
  • Add OPTIONAL_WASM_LIBS. Used in make clean and make all. All libs should add themselves either to this variable or to DEFALT_WASM_LIBS.

With this I can build the rgdal package. It is not fully functional yet but I'd like to get these changes merged before tackling the rest.

@lionel-
Copy link
Member Author

lionel- commented May 12, 2023

The build is failing with:

error: undefined symbol: emscripten_longjmp (referenced by top-level compiled C/C++ code)

This means that some code was compiled with -s SUPPORT_LONGJMP=emscripten instead of -s SUPPORT_LONGJMP=wasm.

@georgestagg
Copy link
Member

georgestagg commented May 12, 2023

According to https://emscripten.org/docs/porting/setjmp-longjmp.html, -s SUPPORT_LONGJMP=emscripten is the default, unless -fwasm-exception is given, in which case the default becomes -s SUPPORT_LONGJMP=wasm.

So, since we only just recently turned on -fwasm-exception perhaps we also need to set -s SUPPORT_LONGJMP=emscripten so that the longjump implementation used by Emscripten is returned to where it was before?

@lionel-
Copy link
Member Author

lionel- commented May 12, 2023

This section is a bit confusing, they also say:

To use the WebAssembly EH and setjmp-longjmp support together:
em++ -fwasm-exceptions -sSUPPORT_LONGJMP=wasm test.cpp -o test.js

So that's what I've used to be sure.

@georgestagg
Copy link
Member

georgestagg commented May 15, 2023

Looks like the issue might be in the Emscripten ports version of FreeType. I can see when building in the docker image that /opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libfreetype.a contains a reference to the emscripten_longjmp symbol.

I'll branch from this PR and experiment with building our own version of FreeType to see if that avoids the issue.

@georgestagg
Copy link
Member

georgestagg commented May 15, 2023

The issue with FreeType has been fixed since Emscripten v3.1.35 (emscripten-core/emscripten#19001). So, I spent some time today updating the GHA docker image to Emscripten v3.1.37, so as to match the version currently installed on my own machine.

In addition, node v17 or later is required for Wasm exceptions, and the version of node installed by emsdk by default is older than that. So, we also need to set an environment variable in GHA CI so that Emscripten uses the newer version of node that's installed by the setup-node action. A PR covering that extra change is at #215, which now builds cleanly in CI.

@lionel-
Copy link
Member Author

lionel- commented May 16, 2023

Thanks for fixing the build!

@georgestagg georgestagg mentioned this pull request May 17, 2023
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