Open waywardmonkeys opened 5 years ago
And it'd be nice if we didn't have to specify HARFBUZZ_SYS_NO_PKG_CONFIG
for emscripten builds...
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 :)
Is it possible to compile to wasm32-unknown-unknown
What is the status of building for Rust projects for WebAssembly that would like to use this dependency (and FreeType)?
Right now, Pathfinder can build in wasm and works, but text is disabled because HB doesn't build.
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.
@dabreegster I hope it will take less than half a year to finish it...
HarfBuzz compiles to WASM, several projects do this already (not combined with rust, thought), see https://github.com/harfbuzz/harfbuzzjs
Has anybody wired up harfbuzzjs
with https://crates.io/crates/harfbuzz-sys?
Edit: Oops, that's what this bug is for. :P
harfbuzzjs +1
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.
I suspect it would be better for projects that depend on this crate to migrate to RustyHarfbuzz instead.
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?
Are there things that rust-harfbuzz does that RustyHarfbuzz does not?
RustyBuzz has a subset of the features from HarfBuzz, but I believe those mostly don't relate to shaping. Possibly Pathfinder doesn't use those extra features?
Is there any solution to use harfbuzz with wasm32-unknown-unknown target or replace it with rust port?
Is there any solution to use harfbuzz with wasm32-unknown-unknown target or replace it with rust port?
RustyBuzz is likely to suit your needs. We're using it successfully in Graphite at https://editor.graphite.rs
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:
The
build.rs
needs to have it use thecmake
code path, so I had just done this for now:Then, I had modified the bundled
harfbuzz-sys/harfbuzz/CMakeLists.txt
to skip theAPPLE
section so that it doesn't try to build CoreText support or link against ApplicationServices.The section here is:
Once I did that, I can get a working build and run the tests manually:
This looks like I need to tell
emcc
to have-s DISABLE_EXCEPTION_CATCHING=0
... but I hadn't done that yet.