-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File "C:\emsdk-main\upstream\emscripten\tools\cache.py", line 68, in lock acquire_cache_lock(reason) #22941
Comments
Which version of emsdk are you using? I can't seem to reproduce this running
Can you confirm, that that command is that one that fails for you? |
I can reproduce this now:
|
Can you try running |
I think this is essentially the same issue as #20204 |
Because some possible dependencies of these libraries have `-mt` variants (specifically png and harfbuzz) we also needs to declare `-mt` variant of these libraries. The reason for this is a little complex: When we find the set of transitive dependencies of given library we select the correct variant of each library. This means that if we are building with `-pthread` then we select and include the `-mt` variants of all dependencies. However if libsdl2_image or libsdl2_ttf themselves then need to be built we end up building them without `-pthread` which means that emcc subprocesses will try to select and build the single threaded variants of the dependencies. This is mostly a serious problem because we don't allow for nested calls to emcc (we assume all dependencies have been already built before we try to build a given library and the we error out with `EM_CACHE_IS_LOCKED` if that is not the case). Testing this fix requires the cache to be setup just right so I'm not sure its worth it. Fixes: emscripten-core#22941, emscripten-core#20204
Because some possible dependencies of these libraries have `-mt` variants (specifically png and harfbuzz) we also needs to declare `-mt` variant of these libraries. The reason for this is a little complex: When we find the set of transitive dependencies of given library we select the correct variant of each library. This means that if we are building with `-pthread` then we select and include the `-mt` variants of all dependencies. However if libsdl2_image or libsdl2_ttf themselves then need to be built we end up building them without `-pthread` which means that emcc subprocesses will try to select and build the single threaded variants of the dependencies. This is mostly a serious problem because we don't allow for nested calls to emcc (we assume all dependencies have been already built before we try to build a given library and the we error out with `EM_CACHE_IS_LOCKED` if that is not the case). Testing this fix requires the cache to be setup just right so I'm not sure its worth it. Fixes: emscripten-core#22941, emscripten-core#20204
error persists even with --lto or --lto --force |
A fix is in flight: #22946 |
Because some possible dependencies of these libraries have `-mt` variants (specifically png and harfbuzz) we also needs to declare `-mt` variant of these libraries. The reason for this is a little complex: When we find the set of transitive dependencies of given library we select the correct variant of each library. This means that if we are building with `-pthread` then we select and include the `-mt` variants of all dependencies. However if libsdl2_image or libsdl2_ttf themselves then need to be built we end up building them without `-pthread` which means that emcc subprocesses will try to select and build the single threaded variants of the dependencies. This is mostly a serious problem because we don't allow for nested calls to emcc (we assume all dependencies have been already built before we try to build a given library and the we error out with `EM_CACHE_IS_LOCKED` if that is not the case). Testing this fix requires the cache to be setup just right so I'm not sure its worth it. Fixes: emscripten-core#22941, emscripten-core#20204
still cant compile :/ |
I'm having trouble replicating. Are you sure you are using the fix from #22946? |
I was able to replicate the your error before #22946 landed but not after so I think maybe you don't have the fix. Did you do |
i did: emsdk update && emsdk install latest will try with install tot |
emsdk.bat update still cant compile - but get way further -> now it the untested code of DevilutionX can be the problem -> will look into it when i have more time thank you :) |
Great news. Glad that old bug is finally fixed. |
btw - you should also edit your manual: emsdk.bat should NEVER been in an admin CMD :) |
Perhaps you could elaborate? What kind of problems? Could you perhaps open new bug in the emsdk repo for that? |
latest emscripten installed today
VS2022 installed today
commands for compiling:
File "C:\emsdk-main\upstream\emscripten\tools\cache.py", line 68, in lock
acquire_cache_lock(reason)
File "C:\emsdk-main\upstream\emscripten\tools\cache.py", line 42, in acquire_cache_lock
assert 'EM_CACHE_IS_LOCKED' not in os.environ, f'attempt to lock the cache while a parent process is holding the lock ({reason})'
AssertionError: attempt to lock the cache while a parent process is holding the lock (sysroot\lib\wasm32-emscripten\thinlto\libSDL2.a)
googled it and found same error in 2020 and 2023 -> all said its fixed on windows -> but it isnt
actually first time i didnt use
but i restarted pc
full log: emsdk-err.log
The text was updated successfully, but these errors were encountered: