WebAssembly support

[waywardmonkeys]

I'm partially able to get a hacked up local build with WebAssembly locally as something that I'd been playing with, but I saw that @pcwalton is also working on this ... so I'll share what I know here:

I was doing:

PATH=~/Development/emscripten:$PATH HARFBUZZ_SYS_NO_PKG_CONFIG=1 cargo test --target wasm32-unknown-emscripten --features=build-native-harfbuzz --no-run

The build.rs needs to have it use the cmake code path, so I had just done this for now:

-    if target.contains("windows") {
+    if target.contains("windows") || target.contains("emscripten") {

Then, I had modified the bundled harfbuzz-sys/harfbuzz/CMakeLists.txt to skip the APPLE section so that it doesn't try to build CoreText support or link against ApplicationServices.

The section here is:

if (APPLE AND HB_HAVE_CORETEXT)

Once I did that, I can get a working build and run the tests manually:

node ../target/wasm32-unknown-emscripten/debug/deps/harfbuzz_sys-d3b521c3c3fe5aaa.js

running 15 tests
test bindgen_test_layout__hb_var_int_t ... ok
test bindgen_test_layout_hb_aat_layout_feature_selector_info_t ... ok
test bindgen_test_layout_hb_feature_t ... ok
test bindgen_test_layout_hb_font_extents_t ... ok
test bindgen_test_layout_hb_glyph_extents_t ... ok
test bindgen_test_layout_hb_glyph_info_t ... ok
test bindgen_test_layout_hb_glyph_position_t ... ok
test bindgen_test_layout_hb_ot_color_layer_t ... ok
test bindgen_test_layout_hb_ot_math_glyph_part_t ... ok
test bindgen_test_layout_hb_ot_math_glyph_variant_t ... ok
exception thrown: ReferenceError: _setThrew is not defined,ReferenceError: _setThrew is not defined
    at invoke_viiii (/Users/bruce/Development/endoli/rust-harfbuzz/target/wasm32-unknown-emscripten/debug/deps/harfbuzz_sys-d3b521c3c3fe5aaa.js:5806:5)
    at __ZN3std9panicking18continue_panic_fmt17h8da0cc447534547bE (wasm-function[696]:232)
    at __ZN3std9panicking15begin_panic_fmt17h1e4b0c823bda4a29E (wasm-function[695]:173)
    at __ZN12harfbuzz_sys38bindgen_test_layout_hb_ot_name_entry_t17h33662a45aab25317E (wasm-function[108]:1037)
    at __ZN12harfbuzz_sys38bindgen_test_layout_hb_ot_name_entry_t28__u7b__u7b_closure_u7d__u7d_17h3396e4a55b0eff6cE (wasm-function[130]:30)
    at dynCall_vi (wasm-function[1181]:14)
    at Module.dynCall_vi (/Users/bruce/Development/endoli/rust-harfbuzz/target/wasm32-unknown-emscripten/debug/deps/harfbuzz_sys-d3b521c3c3fe5aaa.js:6131:38)
    at invoke_vi (/Users/bruce/Development/endoli/rust-harfbuzz/target/wasm32-unknown-emscripten/debug/deps/harfbuzz_sys-d3b521c3c3fe5aaa.js:5758:5)
    at __ZN4core3ops8function6FnOnce9call_once17hbdf62de6b20e5c0eE (wasm-function[165]:46)
    at __ZN4test28__rust_begin_short_backtrace17h5ca4862777d64d58E (wasm-function[342]:17)

This looks like I need to tell emcc to have -s DISABLE_EXCEPTION_CATCHING=0 ... but I hadn't done that yet.

[waywardmonkeys]

And it'd be nice if we didn't have to specify HARFBUZZ_SYS_NO_PKG_CONFIG for emscripten builds...

[matheus23]

Hello.

I know that there is only preliminary build support for webassembly. However, I wanted to notify you that for me, building for webassembly results in a multiple definition linker error on master:

/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.bss._hb_CrapPool+0x0): multiple definition of `_hb_CrapPool'; CMakeFiles/main.dir/src/main.cc.o:(.bss._hb_CrapPool+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_NullPool+0x0): multiple definition of `_hb_NullPool'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_NullPool+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_OT_LangSys+0x0): multiple definition of `_hb_Null_OT_LangSys'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_OT_LangSys+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_OT_RangeRecord+0x0): multiple definition of `_hb_Null_OT_RangeRecord'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_OT_RangeRecord+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o): in function `_hb_ot_name_language_for_ms_code(unsigned int)':
harfbuzz.cc:(.text._Z32_hb_ot_name_language_for_ms_codej+0x0): multiple definition of `_hb_ot_name_language_for_ms_code(unsigned int)'; CMakeFiles/main.dir/src/main.cc.o:main.cc:(.text._Z32_hb_ot_name_language_for_ms_codej+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o): in function `_hb_ot_name_language_for_mac_code(unsigned int)':
harfbuzz.cc:(.text._Z33_hb_ot_name_language_for_mac_codej+0x0): multiple definition of `_hb_ot_name_language_for_mac_code(unsigned int)'; CMakeFiles/main.dir/src/main.cc.o:main.cc:(.text._Z33_hb_ot_name_language_for_mac_codej+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o): in function `hb_face_t::load_num_glyphs() const':
harfbuzz.cc:(.text._ZNK9hb_face_t15load_num_glyphsEv+0x0): multiple definition of `hb_face_t::load_num_glyphs() const'; CMakeFiles/main.dir/src/main.cc.o:main.cc:(.text._ZNK9hb_face_t15load_num_glyphsEv+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o): in function `hb_face_t::load_upem() const':
harfbuzz.cc:(.text._ZNK9hb_face_t9load_upemEv+0x0): multiple definition of `hb_face_t::load_upem() const'; CMakeFiles/main.dir/src/main.cc.o:main.cc:(.text._ZNK9hb_face_t9load_upemEv+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_AAT_Lookup+0x0): multiple definition of `_hb_Null_AAT_Lookup'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_AAT_Lookup+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_AAT_SettingName+0x0): multiple definition of `_hb_Null_AAT_SettingName'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_AAT_SettingName+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_OT_CmapSubtableLongGroup+0x0): multiple definition of `_hb_Null_OT_CmapSubtableLongGroup'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_OT_CmapSubtableLongGroup+0x0): first defined here
/usr/bin/ld: libharfbuzz.a(harfbuzz.cc.o):(.rodata._hb_Null_OT_Index+0x0): multiple definition of `_hb_Null_OT_Index'; CMakeFiles/main.dir/src/main.cc.o:(.rodata._hb_Null_OT_Index+0x0): first defined here

The commit 0d6d0cb from #155 works fine.

I ran a git bisect and found that this commit introduced the problem:

3ec3ccca25313dce444c1225146fe815d8f262a8 is the first bad commit
commit 3ec3ccca25313dce444c1225146fe815d8f262a8
Author: Bruce Mitchener <bruce.mitchener@gmail.com>
Date:   Thu Aug 15 23:25:35 2019 +0700

    Update to harfbuzz 2.6.1.

I would love to contribute to fixing this, however I am by no means an expert when it comes to C builld systems. If I can help in any way, please let me know!

Thank you :)

[SetLinux]

Is it possible to compile to wasm32-unknown-unknown

[Keavon]

What is the status of building for Rust projects for WebAssembly that would like to use this dependency (and FreeType)?

[pcwalton]

Right now, Pathfinder can build in wasm and works, but text is disabled because HB doesn't build.

[dabreegster]

In case you haven't seen it, @RazrFalcon is incrementally porting harfbuzz to pure Rust: https://github.com/RazrFalcon/rustybuzz, which will allow it to be compiled to wasm.

[RazrFalcon]

@dabreegster I hope it will take less than half a year to finish it...

[khaledhosny]

HarfBuzz compiles to WASM, several projects do this already (not combined with rust, thought), see https://github.com/harfbuzz/harfbuzzjs

[dabreegster]

Has anybody wired up harfbuzzjs with https://crates.io/crates/harfbuzz-sys?

Edit: Oops, that's what this bug is for. :P

[yisibl]

harfbuzzjs +1

[Keavon]

It's also worth mentioning now that @RazrFalcon's RustyBuzz port is now done. I realize @pcwalton is no longer employed to work on this project but I wonder if a community member may be able to replace HarfBuzz with RustyBuzz.

[jdm]

I suspect it would be better for projects that depend on this crate to migrate to RustyHarfbuzz instead.

[Keavon]

I suspect it would be better for projects that depend on this crate to migrate to RustyHarfbuzz instead.

Isn't this mostly useful for rasterization of the glyphs once they are shaped? Is that still possible after feeding them through RustyBuzz if it's compiled without C dependencies? Or is there a better non-C alternative for the glyph rasterization step after shaping?