freetype port: add variant for standardized Wasm EH (WASM_LEGACY_EXCEPTIONS=0)

[leehyeonseop]

Summary

The freetype port's SUPPORT_LONGJMP=wasm variant (freetype-legacysjlj) hardcodes WASM_LEGACY_EXCEPTIONS: 1, forcing legacy exception handling instructions. Projects using standardized Wasm EH (-fwasm-exceptions -sWASM_LEGACY_EXCEPTIONS=0 -sSUPPORT_LONGJMP=wasm) cannot link with this port without hitting:

WebAssembly.instantiate(): Compiling function failed:
module uses a mix of legacy and new exception handling instructions

Changes

• Add a new variant freetype-wasmsjlj with WASM_LEGACY_EXCEPTIONS: 0
• Update get_lib_name() to return libfreetype-wasmsjlj.a when SUPPORT_LONGJMP=wasm and WASM_LEGACY_EXCEPTIONS=0
• Append -fwasm-exceptions and -sWASM_LEGACY_EXCEPTIONS=0 to build flags for the new variant

Reproduction

# CMakeLists.txt (Emscripten project)
target_link_options(myapp PUBLIC
  "SHELL:-fwasm-exceptions"
  "SHELL:-sWASM_LEGACY_EXCEPTIONS=0"
  "SHELL:-sSUPPORT_LONGJMP=wasm"
  "SHELL:-sUSE_FREETYPE=1"
)

The existing freetype-legacysjlj variant and its behavior are unchanged. Other ports with similar WASM_LEGACY_EXCEPTIONS: 1 hardcoding (e.g. harfbuzz, sdl2_ttf) may need the same treatment in follow-up PRs.

[sbc100]

You you update the test_freetype test in test_other such that it triggers the issue this fixes. It does look like do currently build this configuration:

$ ./test/runner other.test_freetype* -v
using verbose test runner (verbose output requested)
Running 4 tests
Using 4 parallel test processes
[1/4] test_freetype_with_pthreads (test_other.other.test_freetype_with_pthreads) ... ok
[2/4] test_freetype_wasm (test_other.other.test_freetype_wasm) ... ok
[3/4] test_freetype_wasm_legacy (test_other.other.test_freetype_wasm_legacy) ... ok
[4/4] test_freetype_emscripten (test_other.other.test_freetype_emscripten) ... ok

[leehyeonseop]

You you update the test_freetype test in test_other such that it triggers the issue this fixes. It does look like do currently build this configuration:

$ ./test/runner other.test_freetype* -v
using verbose test runner (verbose output requested)
Running 4 tests
Using 4 parallel test processes
[1/4] test_freetype_with_pthreads (test_other.other.test_freetype_with_pthreads) ... ok
[2/4] test_freetype_wasm (test_other.other.test_freetype_wasm) ... ok
[3/4] test_freetype_wasm_legacy (test_other.other.test_freetype_wasm_legacy) ... ok
[4/4] test_freetype_emscripten (test_other.other.test_freetype_emscripten) ... ok

Added test_freetype_wasm_eh in test_other.py with a companion test_freetype_exc.cpp

The test builds a C++ file that uses both try/catch (to emit new-EH instructions) and FT_Init_FreeType() (to link FreeType) with -fwasm-exceptions -sWASM_LEGACY_EXCEPTIONS=0 -sSUPPORT_LONGJMP=wasm.

It verifies via -v build output that libfreetype-wasmsjlj.a (new-EH variant) is selected, not libfreetype-legacysjlj.a. Without the fix the assertion fails because the port falls back to the legacy variant.

Note: The test runner uses Node.js 22 with --experimental-wasm-exnref. In our testing, this configuration runs the mixed-EH binary without error, so the runtime instantiation failure cannot be reproduced here. The test therefore verifies the correct port variant by checking the library name in -v build output

[sbc100]

Remove this here and below?