emscripten/emsdk:3.1.20: size_t has size 7 with -pthread and 4 without

[sophonet]

Hi guys,

with a docker-based toolchain (based on emscripten/emsdk:3.1.20 image) I have stumbled over the following issue: When configuring a CMake project and I have set the environment variable export CXXFLAGS="-pthread" before to build a project with threads. This results in size_t to have 7 bytes (it has 4 without the flag) and leads to an issue for compiling e.g. the tiff library expects a size of 4 or 8 (https://gitlab.com/libtiff/libtiff/-/blob/master/cmake/TypeSizeChecks.cmake).

I have checked this with the CMake snippet below.

Any hints? To me, 7 bytes look actually wrong...

Thanks,

Sophonet

---

INCLUDE (CheckTypeSize)
set(CMAKE_EXTRA_INCLUDE_FILES ${CMAKE_EXTRA_INCLUDE_FILES} "stddef.h")
check_type_size("size_t" SIZEOF_SIZE_T)
MESSAGE(FATAL_ERROR "And it is *${SIZEOF_SIZE_T}*")

[sophonet]

Found out myself. If pthread is added, CMake cannot run the compiled wasm, since node does not support it. The error code 7 is returned as size. Will file an issue.

[sbc100]

What version of emscripten are you using? IIUC this issue should have been fixed in #15590. This change make it into version 3.0.1.

When you run cmcmake do you see -DCMAKE_CROSSCOMPILING_EMULATOR specified on the command line along with --experimental-wasm-threads? Something like this:

configure: cmake /usr/local/google/home/sbc/dev/wasm/emscripten/test/cmake/pthread --debug-trycompile -DCMAKE_TOOLCHAIN_FILE=/usr/local/google/home/sbc/dev/wasm/emscripten/cmake/Modules/Platform/Emscripten.cmake -DCMAKE_CROSSCOMPILING_EMULATOR=/usr/local/google/home/sbc/dev/wasm/emsdk/node/14.18.2_64bit/bin/node;--experimental-wasm-threads

[sophonet]

Thanks for the hint. So far I have not used emcmake.py but have followed these instructions https://gitlab.kitware.com/vtk/vtk/-/tree/master/Examples/Emscripten/Cxx. Would it make sense to add the experimental-wasm-threads to the CMAKE_TOOLCHAIN_FILE directly such that it is used without emcmake.py?

[sbc100]

Sure that would make sense yes. Are you not using emcmake?

[abram]

I don't know if it's possible, but it would be nice to have better reporting in the case node fails with an error when running the js/wasm generated by check_type_size. The current behavior of using "7" as the result is confusing and hard to debug.

I ran into this issue because I was trying to get threads working in emscripten and I had set -s PTHREAD_POOL_SIZE=navigator.hardwareConcurrency in my CMAKE_CXX_FLAGS instead of more precisely adding the option in linker flags. This apparently was making node fail in check_type_size. But this failure was silent and the only symptom was that SIZEOF_SIZE_T was getting set to 7 and making one of my libraries fail to compile.

Thanks for all your work on Emscripten, it's awesome!

[abram]

Follow up notes my future self, or anyone else who has found your way here and is trying to debug this issue:

Add these lines to your CMakeLists.txt:

include(CheckTypeSize)
check_type_size("size_t" SIZEOF_SIZE_T)
if (SIZEOF_SIZE_T STREQUAL 7)
    message(FATAL_ERROR "check_type_size for size_t returned 7, this means that emcc compiler flags are probably wrong.")
endif()

If this error crops up, run cmake with the additional flags --trace-expand --debug-trycompile. This will add a lot of logging to the CMake output. Look for a line like:

Linking C executable cmTC_1d0d2.js

before the error. Thanks to --debug-trycompile this file will still exist in CMakeFiles/CMakeTmp in your build directory.

Next look at -DCMAKE_CROSSCOMPILING_EMULATOR in the cmake output to see the command that's being used to run the JS file above. It should be something like <EMSDK_DIR>/node/14.18.2_64bit/bin/node;--experimental-wasm-threads. Now you can run this command (replace semicolons with spaces) with the JS file above and see what happens. Probably there will be an error, which you can now debug.

(In my case, the issue this time was #18084)

[sbc100]

I believe this was fixed in #18309, which was released in 3.1.28.

[wonder-sk]

I had the same issue, and actually >= 3.1.29 is needed, because of the followup fix in #18355 that did not get into 3.1.28...