freetype emscripten solution

[Jonathhhan]

I think I found a solution for Emscriptens freetype lib. But not sure how to change this script accordingly: https://github.com/openframeworks/apothecary/blob/bleeding/apothecary/formulas/freetype/freetype.sh I downloaded the latest freetype: https://github.com/freetype/freetype And compiled it like that: https://github.com/emscripten-core/emscripten/issues/10851

mkdir build
cd build
emcmake cmake ..
emmake make
emmake make install

Maybe someone can use it for updating the script?

[Jonathhhan]

Actually it should be build with atomics features, otherwise there are this errors, if build with USE_PTHREADS: wasm-ld: error: --shared-memory is disallowed by sfnt.c.o because it was not compiled with 'atomics' or 'bulk-memory' features.

Most other libs are build with atomics features (because they had those issues, too), but no idea how to enable it here...

Also some warnings, but without USE_PTHREADS it seems to work well:

-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
-- Checking for module 'bzip2'
--   No package 'bzip2' found
-- Could NOT find BrotliDec (missing: BROTLIDEC_INCLUDE_DIRS BROTLIDEC_LIBRARIES)

[danoli3]

Thanks I'll have a look at binding those depends. We still thinking .o instead of .wasm?

Is maybe the final oF make script not searching for correct .wasm or .o files maybe

[Jonathhhan]

In this case it creates an a. file. There was a recent change regarding .bc files (in 3.1.52): emcc will now treat .bc files as source files. This means that they will get compiled by clang before being passed to the linker. This matches the behaviour of clang. #20922 https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md Because of that I had to make some small changes in OF. But I do not think, that it is related to the .wasm issue. In case of pugixml and freetype .wasm did not work, but .o in case of pugixml and .a in case of freetype. Not sure about the reason for that.

[Jonathhhan]

Thats how I did the pthread stuff in the other libs: https://github.com/openframeworks/apothecary/pull/262/files

Found a way to compile freetype with pthread support (and it works):

mkdir build
cd build
emcmake cmake -D CMAKE_C_FLAGS="-pthread" ..
emmake make

[danoli3]

I was reading about PTHREAD and emscripten https://emscripten.org/docs/porting/pthreads.html#compiling-with-pthreads-enabled

And interesting reading on this here: https://decovar.dev/blog/2023/11/20/webassembly-with-pthreads/

[Jonathhhan]

@danoli3 OF with pthreads already works (all of the multithreading examples). But the used precompiled libs need to be build with pthreads, too. It is still possible to build the app without pthread support. The main downside in my opinion is the cors policy: https://stackoverflow.com/questions/76920200/webaudioworklet-in-webassembly-shared-array-buffer-not-defined

And I did not know that and did not experiences any issues so far (but good to be carfeful, at least):

If you want to target browsers that do not support Wasm multithreading, then compiling any code with -pthread will cause issues, since those browsers won't recognize the atomics operations that get emitted.

https://groups.google.com/g/emscripten-discuss/c/kFbIbXAGVd0

[danoli3]

Interesting, their take is offer two compiled versions, with and without pthreads, something we could look into if it's problematic. Sweet. We shall look at the getting core changes merged today

[danoli3]

Okay do we have a consensus somewhere of what the binary/libraries format should be for latest emscripten? And what commands to pass?

Looking into this after VS macOS stuff

[danoli3]

So what was the consensus for emscripten, build into .o files and link to those? This is confusing as hell

[Jonathhhan]

So what was the consensus for emscripten, build into .o files and link to those? This is confusing as hell

@danoli3 yes, I guess so. Can check it this weekend. Sorry for the confusion.

[danoli3]

Almost got all this working now. I think the issue you were experiencing was the mk files were using embedded freetype, and until you called Make install, it overwrote the embedded one essentially.

Got this all working now

[danoli3]

@Jonathhhan can you test out https://github.com/openframeworks/openFrameworks/pull/8056

I today will be adding GLFW support rather than EGL HTML5 context binding (problematic)