Part of the mystery can be solved because clang replaces malloc+memset pairs with a single calloc call (only when optimization is enabled):
https://www.godbolt.org/z/8r3Ydjs6a ...which explains why the problem shows up in release mode, but not debug mode. There still must be something else going on though, because I'm using the malloc+memset combo all the time together with emmalloc (and I guess the missing piece is that the malloc call is going through the function pointer). I'll tinker around a bit more with compiler options (but since this is a library, I cannot dictate what compiler options the code is built with). Cheers! On Monday, 5 September 2022 at 19:31:17 UTC+2 [email protected] wrote: > The other thing this could be related to is LTO. IIUC LTO itself can > generate calls to buildin functions (such as malloc and calloc) that are > not present in the original program. Does disabling LTO fix the problem? > > On Mon, Sep 5, 2022 at 10:28 AM Sam Clegg <[email protected]> wrote: > >> Can you trying building with `-Wl,--trace-symbol=calloc` rather than >> `LLD_REPORT_UNDEFINED=1` (I guess there are still some issues with that >> setting). >> >> Does the link time error tell you why calloc is being pulled in? (The JS >> compiler linker errors should do this but they often just say "top level >> C/C++"). >> >> On Sat, Sep 3, 2022 at 6:03 AM Floh <[email protected]> wrote: >> >>> I just stumbled over a very weird problem in a new sample for my sokol >>> headers which includes a non-trivial 3rd party C library - the spine-c >>> runtime ( >>> https://github.com/EsotericSoftware/spine-runtimes/tree/4.1/spine-c/spine-c >>> ) >>> >>> When building in release mode (but not in debug mode) the linker >>> complains about an unresolved 'calloc' call. Adding detailed output >>> via LLD_REPORT_UNDEFINED=1 I get tons of: >>> >>> wasm-ld: error: >>> /Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libemmalloc.a(emmalloc.o): >>> >>> undefined symbol: calloc >>> >>> ... how does that even make sense when emmalloc is supposed to provide >>> an implementation of calloc... anyway... >>> >>> The error goes away when compiling in debug mode (some differences that >>> come to mind to the release mode is that debug mode doesn't use -flto, and >>> also doesn't run the closure compiler). >>> >>> The problem also goes away when not building with emmalloc. >>> >>> Now the weird thing is that the entire code this sample is built from >>> doesn't appear to call calloc anywhere... and that other samples which >>> actually use calloc build just fines. >>> >>> Has anybody seen a similar problem yet, before I jump myself into the >>> rabbit hole? :) >>> >>> The problematic command line is: >>> >>> em++ -s DISABLE_EXCEPTION_CATCHING=1 -fno-exceptions -fno-rtti >>> -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas >>> -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual >>> -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue >>> -Wno-inconsistent-missing-override -Wno-warn-absolute-paths >>> -Wno-expansion-to-defined -flto -O3 -DNDEBUG -s >>> DISABLE_EXCEPTION_CATCHING=1 --memory-init-file 0 -s >>> INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s >>> NO_EXIT_RUNTIME=1 -s LLD_REPORT_UNDEFINED=1 -s ALLOW_MEMORY_GROWTH=1 -s >>> USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1 >>> --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html -O3 >>> -flto --closure 1 -s ASSERTIONS=0 >>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj >>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj -o >>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.html >>> >>> libs/sokol/libsokol.a libs/spine-c/libspine-c.a libs/stb/libstb.a >>> libs/util/libfileutil.a fips-cimgui_cimgui/libcimgui.a >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/c47cee25-6e4b-4fbe-9f6f-0d7da7e02562n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/emscripten-discuss/c47cee25-6e4b-4fbe-9f6f-0d7da7e02562n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/bf4ae25d-1b47-406a-a109-ecb7bb2ce98bn%40googlegroups.com.
