emcc: undefined symbol: _emscripten_tempret_set

[juliangilbey]

Hi!
I'm helping to package emscripten for Debian, and we've run across a stumbling block. We are using version 3.1.66. The package builds fine, but running the command

emcc /usr/share/emscripten/test/hello_world.c

crashes with the following output:

{
  "declares": [
    "fd_write",
    "_emscripten_memcpy_js",
    "setTempRet0"
  ],
  "globalImports": [
  ],
  "exports": [
    "__wasm_call_ctors",
    "main",
    "fflush",
    "strerror",
    "__get_temp_ret",
    "__set_temp_ret",
    "emscripten_stack_init",
    "emscripten_stack_get_free",
    "emscripten_stack_get_base",
    "emscripten_stack_get_end",
    "_emscripten_stack_restore",
    "_emscripten_stack_alloc",
    "emscripten_stack_get_current",
    "dynCall_jiji"
  ],
  "namedGlobals": {
  },
  "invokeFuncs": [
  ],
  "mainReadsParams": 1,
  "features": [
    "--enable-mutable-globals",
    "--enable-sign-ext",
    "--enable-reference-types",
    "--enable-multivalue"
  ]
}
error: undefined symbol: _emscripten_tempret_set (referenced by $setTempRet0, referenced by setTempRet0, referenced by root reference (e.g. compiled C/C++ code))
warning: To disable errors for undefined symbols use `-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: __emscripten_tempret_set may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors
emcc: error: '/usr/bin/node /usr/share/emscripten/src/compiler.mjs /tmp/tmpgzybk9xd.json' failed (returned 1)

It worked with the previous version in Debian (3.1.6). I couldn't see anything obvious in ChangeLog.md that might suggest that we need to change something. I can see that _emscripten_tempret_set is set in /usr/share/emscripten/system/lib/compiler-rt/emscripten_tempret.s, and it is mentioned in /usr/share/emscripten/tools/link.py, but I can't understand what has gone wrong.

This test is being done by a "clean" using in a clean chroot environment, so they don't have anything configured in their home directory by default (in particular, there is no ~/.emscripten directory).

Any help would be much appreciated! Thanks 😄

[sbc100]

Can you check where you libcompiler_rt.a is coming from? (Adding -v to the command line should show you the link command).

You can then check that emscripten_tempret.s is part of it:

$ llvm-ar t ./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep tempret
emscripten_tempret.o
$ llvm-nm ./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep tempret
0000000c T _emscripten_tempret_get
00000001 T _emscripten_tempret_set

[juliangilbey]

Thanks @sbc100!

With -v, the output includes:

 /usr/bin/node /usr/share/emscripten/src/compiler.mjs /tmp/tmp41echsez.json --symbols-only
 /usr/bin/wasm-ld-19 -o a.out.wasm -L/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten /tmp/emscripten_temp_cuqq3dyx/hello_world_0.o -lGL-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-debug-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /tmp/tmpg69gegq6libemscripten_js_symbols.so --strip-debug --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=_emscripten_stack_alloc --export=__get_temp_ret --export=__set_temp_ret --export=__wasm_call_ctors --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --stack-first --table-base=1
 /usr/bin/llvm-objcopy-19 a.out.wasm a.out.wasm --remove-section=.debug* --remove-section=producers
 /usr/bin/wasm-emscripten-finalize --dyncalls-i64 --pass-arg=legalize-js-interface-exported-helpers a.out.wasm -o a.out.wasm --detect-features

So the link command includes -lcompiler_rt, but no mention of libcompiler_rt.a. I ran the emcc command under strace and found this openat syscall:

1105660 openat(AT_FDCWD, "/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a", O_RDONLY|O_CLOEXEC) = 3

The llvm commands:

$ llvm-ar t /usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep tempret
emscripten_tempret.o
$ llvm-nm /usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep tempret
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:apple_versioning.o: no symbols
emscripten_tempret.o:
0000000c T _emscripten_tempret_get
00000001 T _emscripten_tempret_set
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:extendhftf2.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:os_version_check.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trampoline_setup.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trunctfhf2.o: no symbols

It has the tempret symbols, but I'm not so happy about the missing symbols warnings. I have no idea if this is related, though.

I'm still stumped :/

[sbc100]

The "no symbols" warnings a normal and can be ignored.

So, the symbol exists in the library but is not being exported.

I think the problem here might be that you are trying to use llvm-19 (wasm-ld-19) and emscripten could be relying on some linker feature that is not in llvm-19. In general emscripten is not designed to work with stable llvm releases, only with the specific tip-of-tree version that it was built with.

Can you try using the version of wasm-ld that ships with emsdk and see if that fixes your issue?

Also, can you attach the full output of the command with EMCC_DEBUG=1 set?

[sbc100]

Can you verify that setTempRet0 is also defined in emscripten_tempret.o?

$  llvm-nm ./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep setTempRet0
./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:apple_versioning.o: no symbols
./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:00000001 T setTempRet0
extendhftf2.o: no symbols
./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:os_version_check.o: no symbols
./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trampoline_setup.o: no symbols
./cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trunctfhf2.o: no symbols

[juliangilbey]

I also tried this with emscripten 3.1.64, which was based on llvm-19, and got the same problem. But I think your second comment might have found the problem:

$ llvm-nm /usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep setTemRet0
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:apple_versioning.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:extendhftf2.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:os_version_check.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trampoline_setup.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trunctfhf2.o: no symbols

So setTempRet0 is not defined... That's weird. Where should it have been included, and where can I look to dig into why it wasn't?

EMCC_DEBUG=1 output attached, too.

Thanks so much for your help! We'll get this into Debian ;-)
emcc-debug.txt

[sbc100]

I strongly recommend vendoring in your own version of llvm rather than trying to use the stable/system version. emscripten does not currently support stable versions of llvm. See #11362 for more on this.

[juliangilbey]

Thanks for the pointer! I just read that issue, and see the discussion between you and Jonas, from the time he was maintaining the Debian emscripten package. Nothing has really changed from the Debian side: embedding a ToT llvm in emscripten isn't going to happen in Debian. I'm happy to stick with the "latest compatible version", but so far I've tried 3.1.64 (which still said LLVM version 19), and that has the same problem. If we need to revert to an older version of emscripten, I'd be fine with doing that, too, if that is the cause of this issue.

[sbc100]

The problem is there is no "latest compatible version". In order to find the version of emscripten most likely to work with llvm-19 you would need to go back though the emscripten-releases history and find the release that includes a version of llvm closest to the llvm-19 branch point.

To do this you would need to look at the history of this file: https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/DEPS.tagged-release. Within it you would want to look at the value of llvm_project_revision and compare it to the llvm-19 branch point.

The closer you get the more likely you are to have a working version of emscripten.. but there is no guarantee sadly.

[juliangilbey]

OK, understood. Will take a look at that next week, then.

[juliangilbey]

Oh, duh, typo:

$ llvm-nm /usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a | grep setTempRet0
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:apple_versioning.o: no symbols
00000001 T setTempRet0
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:extendhftf2.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:os_version_check.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trampoline_setup.o: no symbols
/usr/share/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a:trunctfhf2.o: no symbols

So it is there.