Fix {cachdir} typo in error message

[benoit-pierre]

emcc: error: unable to create cache directory "{cachdir}": parent directory not writable (see https://emscripten.org/docs/tools_reference/emcc.html for info on setting the cache directory)

[benoit-pierre]

And it's not expanded either… And why is emscripten trying to create said directory in /usr/lib/emscripten/cache?

[sbc100]

And it's not expanded either… And why is emscripten trying to create said directory in /usr/lib/emscripten/cache?

It looks like somehow you have a copy of emscripten in /usr/lib/emscripten/ and maybe you are either using its config file, or running emcc from that location.

Can you attach the output of your emcc command with EMCC_DEBUG=1 set? It should tell us what is going on

[benoit-pierre]

I'm on Arch Linux, using the official package (emscripten 3.1.71-2).

▸ EMCC_DEBUG=1 emcc
config:DEBUG: using config file: /usr/lib/emscripten/.emscripten
tools.filelock:DEBUG: Attempting to acquire lock 130620270418768 on /tmp/emscripten_temp/emscripten.lock
tools.filelock:DEBUG: Lock 130620270418768 acquired on /tmp/emscripten_temp/emscripten.lock
profiler:DEBUG: block "read_ports" took 0.014 seconds
emcc:WARNING: invocation: /usr/lib/emscripten/emcc.py (in /home/bpierre)
profiler:DEBUG: block "parse arguments" took 0.000 seconds
emcc: error: unable to create cache directory "{cachdir}": parent directory not writable (see https://emscripten.org/docs/tools_reference/emcc.html for info on setting the cache directory)
profiler:DEBUG: block "check_sanity" raised an exception after 0.000 seconds
profiler:DEBUG: block "main" raised an exception after 0.000 seconds
tools.filelock:DEBUG: Attempting to release lock 130620270418768 on /tmp/emscripten_temp/emscripten.lock
tools.filelock:DEBUG: Lock 130620270418768 released on /tmp/emscripten_temp/emscripten.lock

▸ cat /usr/lib/emscripten/.emscripten
NODE_JS = '/usr/bin/node'
LLVM_ROOT = '/opt/emscripten-llvm/bin'
BINARYEN_ROOT = '/usr'
EMSCRIPTEN_ROOT = '/usr/lib/emscripten'

▸ cat /etc/profile.d/emscripten.sh
#!/bin/sh
export PATH=$PATH:/usr/lib/emscripten

For now I've resorted to setting EM_CACHE explicitly.

[benoit-pierre]

No issue when downgrading to 3.1.67-1. I guess the change of behavior is due to 48d9bc0.

[sbc100]

Ah I see. Yes the problem is that /usr/lib/emscripten/.emscripten should really suggest a R/W location for the emscripten cache (or set FROZEN_CACHE). The default fallback of $HOME/.emscripten_cache was removed in #22801.

Which distro are you using? We should suggest that they add an explicit an EM_CACHE

[benoit-pierre]

Arch Linux.

[sbc100]

Thanks. We should reach out to the maintainers of the arch linux emscripten package to let them know they need to update the config file.

[sbc100]

Ah it looks like that is @svenstaro

[benoit-pierre]

https://gitlab.archlinux.org/archlinux/packaging/packages/emscripten/-/issues/1

[svenstaro]

What's the upstream recommendation for this case? Should we set EM_CACHE to some XDG value?

[sbc100]

We tend to recommend/use a single shared sysroot (cache) and the recommended location is inside the emscripten directory itself. Obviously that doesn't work if the emscripten location is not writable, as in this case.

One problem with using $HOME/$XDG is that if a user is wanting to switch between mulutple versions of emscripten then the cache becoming invlidated and is cleared each time they switch (which is why I tent to prefer / recommend a separate cache dir alongside (inside) each version of emscripten).

Having said all that, the XDG cache directory seems like the best we can do in your case I think.

One alternative is to use a read-only cache that only root can populate. This is more like a normal toolchain, right? If you want to do that you would set FROZEN_CACHE in your config file, and then it would require the root user to build/populate/update the sysroot, instead of the default which is to build stuff on demand.

[svenstaro]

Can I somehow prepopulate that during build time? That would be ideal!

[sbc100]

Can I somehow prepopulate that during build time? That would be ideal!

You can yes, however there are a lot of possible variants of system libraries and you might not want to include them all. The tool to populate the case is called embuilder and we use that when we build the emsdk distribution. However we don't build all variants of all libraries a that would a lot of time. You can try ./embuilder build ALL and/or ./embuilder build MINIMAL but you might also want --lto variants and --wasm64 variants and --wasm64 + --lto variants.

[sbc100]

I guess you could also package those libraries as separate packages? In any case, once you then set FROZEN_CACHE in the config then your users would get errors on missing libraries, instead of auto-building on-demand.