PermissionError: [Errno 13] Permission denied: '/usr/lib/emscripten/cache.lock'

[jendrikw]

Hi, I just installed emscripten 1.39.16 via the Arch Linux package.

When I run emcc --version I get this onm the first run:

==============================================================================
Welcome to Emscripten!

This is the first time any of the Emscripten tools has been run.

A settings file has been copied to ~/.emscripten, at absolute path: /home/jendrik/.emscripten

It contains our best guesses for the important paths, which are:

  LLVM_ROOT       = /usr/bin
  NODE_JS         = /usr/bin/node
  EMSCRIPTEN_ROOT = /usr/lib/emscripten

Please edit the file if any of those are incorrect.

This command will now exit. When you are done editing those paths, re-run it.
==============================================================================

When I run it again, I get an error:

Traceback (most recent call last):
  File "/usr/lib/emscripten/emcc.py", line 42, in <module>
    import emscripten
  File "/usr/lib/emscripten/emscripten.py", line 25, in <module>
    from tools import shared
  File "/usr/lib/emscripten/tools/shared.py", line 3501, in <module>
    check_vanilla()
  File "/usr/lib/emscripten/tools/shared.py", line 660, in check_vanilla
    is_vanilla_file = temp_cache.get('is_vanilla.txt', get_vanilla_file)
  File "/usr/lib/emscripten/tools/cache.py", line 110, in get
    self.acquire_cache_lock()
  File "/usr/lib/emscripten/tools/cache.py", line 60, in acquire_cache_lock
    self.filelock.acquire(60)
  File "/usr/lib/emscripten/tools/filelock.py", line 240, in acquire
    self._acquire()
  File "/usr/lib/emscripten/tools/filelock.py", line 360, in _acquire
    fd = os.open(self._lock_file, open_mode)
PermissionError: [Errno 13] Permission denied: '/usr/lib/emscripten/cache.lock'

Why is it trying to write in /usr/lib/emscripten?

[louisabraham]

Haha, I just came to post the same issue (on manjaro). I ended up doing a chown on the directory but it is not ideal.

[kripken]

I think this may be related to @sbc100 's recent changes to make emscripten use a different place for the cache, rather than the user's home directory. But I'm not sure since /usr/lib/emscripten/ is the path here. As this is on arch, however, perhaps that's where it puts things, and that has the wrong permissions? (so possibly a change is needed on arch, but maybe we can work around that on emscripten to undo the recent change partially)

[sbc100]

This should be fixed in top of tree.

See #11301

[jendrikw]

@sbc100 Thanks. When is a release planned?

[sbc100]

Today I hope.

Is using 1.39.15 not an option for you? Is that even possible with arch linux?

You can also set EM_CONFIG=$HOME/.emscripten to solve this issue.

[jendrikw]

You can downgrade packages, but it's severely discouraged because of dependencies which may also be downgraded. It has basically the same issues as mixing repositories in Debian. See also https://wiki.archlinux.org/index.php/Downgrading_packages.

[sbc100]

How does the upgrade process work? Its seems like this package must have been releases with basically zero testing.

Does the EM_CONFIG=$HOME/.emscripten solution for you for now?

[sbc100]

@svenstaro is there some way to could run some basic tests before releasing new versions of the arch linux package?

[svenstaro]

Sadly, due to limitations in our packaging infrastructure, we can't automatically run tests of the to-be-installed package after its packaging and with user permissions. We can only run basic software suite tests such as make test. I couldn't get your python tests/runner.py to run as it depends on the software being installed prior to running.

I do usually run emcc -v manually but I usually don't unset my EM_CONFIG so I don't think I would have noticed.

Since you want to deprecate the implicit $HOME-based cache/config dir, I have to wonder: How do you want downstream packagers to set a user-writable default dir for the config and cache?

That said, a release soon would be appreciated as the patch of the MR doesn't apply cleanly.

[sbc100]

Great question! I've tried to document some of this in the new docs/packaging.md.

I think it would be great if downstream distos would ship an embedded .emscripten within the installation directory. That way you can point to the correct versions of llvm, binaryen, and node for your disto. This is how emsdk already works and I think it would be great if all packaged version of emscripten worked like this.

You could also set "CACHE = ~/.emscripten" in that file.. or you could let the new code that detects the read-only installation fall back to this.

the added benefit of this is that you won't see that first use message when emcc if first run asking you to configure it. It should "just work" on first use.

[sbc100]

Regarding testing.. ah I see.. makes sense. This issue would only show up in some kind of true post-installation testing.

[svenstaro]

I'll try that. Related: Can we now finally use system LLVM without compiling a custom version for Emscripten? I'd much prefer that as we'd get fewer duplications that way, a smaller package and less complexity all around.

[sbc100]

Eventually it would be nice to use the system version of LLVM yes. Perhaps starting with LLVM 11 we could support the current LLVM stable as well as ToT (with certainly features only available with ToT).

As of today we do unfortunately depend on LLVM ToT so you can't depend on the system LLVM (unless you can get a ToT packages of LLVM?)

[svenstaro]

I'm now shipping an .emscripten file as you suggested: https://git.archlinux.org/svntogit/community.git/tree/trunk/emscripten-config?h=packages/emscripten

Check out our whole build here: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/emscripten

I believe this issue can now be closed.