Unresolved _tzset_js symbol in libc.a with STANDALONE_WASM + PURE_WASI

[squrky]

Hi,

I'm trying to compile a simple Hello World C++ program to standalone WASM with pure WASI. This is producing a libc that erroneously requires a _tzset_js host function.

Version: 4.0.11-git (be89742)

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.11-git (be897425c3472f96cf77a397f7464ac81b8dc81b)
clang version 21.0.0git (https:/github.com/llvm/llvm-project b5dbf8210a57b986b9802304745f4c5c108cf37b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/builder/emsdk/upstream/bin
Build config: +assertions

I can reliably reproduce this by building a stub program and looking for the existence of _tzset_js in the resulting cached libc.a. Full steps are like this:

builder@d3377dd61f2b:~/repo$ touch dummy.c
builder@d3377dd61f2b:~/repo$ emcc --clear-cache
args:INFO: clearing cache as requested by --clear-cache: `None`
shared:INFO: (Emscripten: Running sanity checks)
builder@d3377dd61f2b:~/repo$ emcc -sPURE_WASI=1 -sMEMORY64=1 -sSTANDALONE_WASM=1 --no-entry -O2 dummy.c -o dummy.wasm
shared:INFO: (Emscripten: Running sanity checks)
cache:INFO: generating system headers: sysroot_install.stamp... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot_install.stamp" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system asset: sysroot/lib/wasm64-emscripten/crt1_reactor.o... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/crt1_reactor.o" for subsequent builds)
system_libs:INFO: compiled 1 inputs in 0.12s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libGL-getprocaddr.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libGL-getprocaddr.a" for subsequent builds)
system_libs:INFO: compiled 4 inputs in 0.27s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libal.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libal.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs in 0.17s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libhtml5.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libhtml5.a" for subsequent builds)
system_libs:INFO: compiled 5 inputs in 0.23s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libstandalonewasm-nocatch-pure.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libstandalonewasm-nocatch-pure.a" for subsequent builds)
system_libs:INFO: compiled 14 inputs in 0.57s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libstubs.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libstubs.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs in 0.17s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libnoexit.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libnoexit.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs in 0.17s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libc.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc.a" for subsequent builds)
system_libs:INFO: compiled 1044 inputs in 10.50s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libdlmalloc.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libdlmalloc.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs in 0.58s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libcompiler_rt.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libcompiler_rt.a" for subsequent builds)
system_libs:INFO: compiled 162 inputs in 1.98s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libc++-noexcept.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc++-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 56 inputs in 14.98s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libc++abi-noexcept.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc++abi-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 16 inputs in 3.25s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm64-emscripten/libsockets.a... (this will be cached in "/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libsockets.a" for subsequent builds)
system_libs:INFO: compiled 27 inputs in 0.92s
cache:INFO:  - ok
builder@d3377dd61f2b:~/repo$ emnm /home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc.a | grep _tzset_js
         U _tzset_js
/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc.a:emulate_wait4.o: no symbols
/home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm64-emscripten/libc.a:vdso.o: no symbols

I'm new to Emscripten but my understanding is that these _js helper functions are provided by the browser and are not supposed to be required for standalone programs. Please correct me if I'm mistaken.

Note: I don't think MEMORY64 mode is strictly required to make this symbol appear. Here's the elided output for a run of the same steps as above but without MEMORY64:

builder@d3377dd61f2b:~/repo$ emcc -sPURE_WASI=1 -sSTANDALONE_WASM=1 --no-entry -O2 dummy.c -o dummy.wasm
builder@d3377dd61f2b:~/repo$ emnm /home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc.a | grep _tzset_js
         U _tzset_js

I'm running this inside a docker container based on Debian Bookworm slim. Here's my Dockerfile for completeness:

FROM debian:bookworm-slim

RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive \
    apt-get install --no-install-recommends --assume-yes \
        sudo \
        git tar lzma xz-utils \
        cmake make ninja-build \
        libatomic1 \
        python3 \
        ca-certificates

# # Create a non‑root user
RUN adduser builder
RUN echo 'builder ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

# Copy .bashrc
COPY docker/.bashrc /home/builder/.bashrc
RUN chown builder:builder /home/builder/.bashrc

USER builder
WORKDIR /home/builder

RUN git clone https://github.com/emscripten-core/emsdk.git && \
    cd emsdk && \
    ./emsdk install tot && \
    ./emsdk activate tot

CMD ["/bin/bash"]

Many thanks.

[sbc100]

This is not particularly surprising, since STANDALONE_WASM and/or PURE_WASI don't have lot of test coverage and are not complete. You can fairly easily end up accidentally including a JS import.

I'd you would like to look into removing this particular one, patches would be welcome.

I'd also recommend looking into wasi-sdk if you want to produce builds that never depend on any JS APIs.

[squrky]

Thanks for the response. I was unsure about using wasi-sdk because it's not clear to me how much of the underlying policy is left for the host implementor to control, and how much is baked into wasi-sdk itself. For example, I would want full control over host functions like fd_write or proc_exit etc.

I see there are one or two other issues on this topic, for eg: WebAssembly/wasi-sdk#222

Any pointers towards further reading would be most helpful. Let me know if you think there is anything else to discuss here, if not I will close this issue.

[sbc100]

Thanks for the response. I was unsure about using wasi-sdk because it's not clear to me how much of the underlying policy is left for the host implementor to control, and how much is baked into wasi-sdk itself. For example, I would want full control over host functions like fd_write or proc_exit etc.

wasi-sdk produces binaries that only depend on wasi standard imports. Its up to the to provide conforming implementations of these functions.

In that sense if you are controlling/implementing the host it would be up to you to provide those. Is that what you are asking?

[squrky]

Yes, I went and read a bit more about wasi-sdk and I understand better now that it provides a complete reimplementation of libc in wasm targeting a standard set of host interfaces. That's good, thanks again for the clarification - closing this issue.