Ok, it gets weirder: If I add the -sEXPORTED_FUNCTIONS=_calloc, the sample links alright, but then doesn't run. There's no crash message on the JS console either, it just sits there with a black screen.
This time it's the same behaviour in release and debug mode, yet debug mode works alright without the EXPORTED_FUNCTIONS option (because it builds with -O0, which triggers the problem). Ok, that's enough "rabbit-holeing" for today. My options for this particular sample currently seem to be: (1) don't use emmalloc (2) don't build with optimizations enabled ...both options suck TBH ;) On Saturday, 3 September 2022 at 16:44:41 UTC+2 Floh wrote: > PPPS: building with "-sEXPORTED_FUNCTIONS=_calloc" also works, but I don't > understand why I need this only for this one specific sample, for a problem > triggered by a library that doesn't even call calloc. I didn't have to deal > with EXPORTED_FUNCTIONS for years (instead EMSCRIPTEN_KEEPALIVE did the > job), and especially never for any C runtime functions. > > Any ideas of what's the issue here would be greatly appreciated. I'll put > the EXPORTED_FUNCTIONS into my build options as a hack for now, but it > would be nice if that wouldn't be needed (especially since I don't > understand the reason, lol). > > Cheers! > > On Saturday, 3 September 2022 at 16:26:07 UTC+2 Floh wrote: > >> Another information tidbit: >> >> Adding a calloc() call in any of the other (very similar) samples always >> works without problems (e.g. I don't need to add calloc to >> EXPORTED_FUNCTIONS as advised by the emsdk linker - I don't use >> EXPORTED_FUNCTIONS anywhere in my compiler settings). >> >> It also works if I remove any calls to that spine-c library in my own >> code (but mind that the spine-c library doesn't call into calloc - emsdk's >> llvm-nm doesn't show any references to calloc in the resulting library). >> >> The only place where I can find a reference to calloc is as 'weak symbol' >> in libemmalloc.a, but I don't understand how any potential problems in >> emmalloc would be triggered by the presence or absence of a random third >> party library that doesn't even call into calloc... >> >> On Saturday, 3 September 2022 at 15:54:37 UTC+2 Floh wrote: >> >>> Ok, it works if I change one thing: setting the -O flag from -O3 to -O0 >>> (-O1 also already breaks). >>> >>> ...also it seems that calloc *is* actually called somewhere (the wasm >>> crashes in the calloc stub when I build with ERROR_ON_UNDEFINED_SYMBOLS=0). >>> But I still think it's not anywhere in my code (e.g. the Spine runtime has >>> CALLOC macros all over the place, but this resolves to a call to a helper >>> function with malloc+memset. >>> >>> >>> On Saturday, 3 September 2022 at 15:21:18 UTC+2 Floh wrote: >>> >>>> PPS: ...looks like I can only go back to SDK version 3.0.0 on ARM Macs, >>>> and the problem already existed in that version. >>>> >>>> On Saturday, 3 September 2022 at 15:16:42 UTC+2 Floh wrote: >>>> >>>>> PS: this is the wasm-ld cmdline: >>>>> >>>>> em++: error: >>>>> '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o >>>>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.wasm >>>>> >>>>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj >>>>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj libs/sokol/libsokol.a >>>>> libs/spine-c/libspine-c.a libs/stb/libstb.a libs/util/libfileutil.a >>>>> fips-cimgui_cimgui/libcimgui.a >>>>> -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto >>>>> >>>>> -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept >>>>> -lc++abi-noexcept -lemmalloc -lc_rt -lsockets -mllvm >>>>> -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj >>>>> -mllvm >>>>> -disable-lsr >>>>> --allow-undefined-file=/var/folders/dz/g9ydwg8973z9nn5bvffcwf3h0000gn/T/tmphqvycm26.undefined >>>>> >>>>> --strip-debug --export-if-defined=main --export-if-defined=stackSave >>>>> --export-if-defined=stackRestore --export-if-defined=stackAlloc >>>>> --export-if-defined=__wasm_call_ctors >>>>> --export-if-defined=__errno_location >>>>> --export-if-defined=malloc --export-if-defined=free >>>>> --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm >>>>> --export-table -z stack-size=5242880 --initial-memory=33554432 >>>>> --entry=main >>>>> --max-memory=2147483648 --global-base=1024' failed (returned 1) >>>>> >>>>> ...I'm now trying to bisect the SDK version to see if this is a >>>>> regression... >>>>> >>>>> On Saturday, 3 September 2022 at 15:03:21 UTC+2 Floh 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/5d4f8c52-f275-44a0-8988-6a0745b3e26cn%40googlegroups.com.
