-
Notifications
You must be signed in to change notification settings - Fork 689
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
[Ubuntu] [3.12.0.0-prerelease] Semaphore does not exist #9993
Comments
I changed branches, did some changes, and the error seems to persist, regardless of whether I
|
It seems the project doesn't built with 9.8.2 so I can't reproduce as-per the instructions:
|
I can't reproduce this on NixOS. To reproduce I entered the Then Perhaps something to do with WSL? |
Results from the repo that @jasagredo tried the flag on:
|
Confirming whether this is a WSL thing would be nice. I might try on a full Ubuntu I have around. |
I just checked in my full Ubuntu, and I get the same error, |
@jasagredo Does this happen when building other projects as well? If I can reproduce in a docker container that would be good. |
I just checked now with |
Hello. I'm also hitting this error on my system when trying to build a simple project generated with System information
To reproduceRun these commands in order.
Build log (failed with error)https://gist.github.com/cloudyluna/b13e7d7569ffa3ad1804ba7ec76813b7 |
@wz1000 investigated this issue and the problem appears to be that the binaries are built and linked against musl but used on a system which uses glibc.
|
This seems like a problematic coupling between GHC and cabal. How can this be fixed? |
If GHC had a command line mode to create the semaphore and managed them itself then this coupling wouldn't exist. I can't think of any other options immediately. |
Could Cabal degrade gracefully and switch to no-semaphore mode automatically? |
This is how it should have worked to begin with. Anything other than either being explicit about the semaphore to other clients or hiding it completely is deep into "implementation-defined behavior"-land. |
It seems like cabal also needs to open the semaphore and wait on it so that there are enough resources to spawn a new ghc process, so I don't see how exactly this would work. Are you suggesting more ghc commands to wait on the semaphore as well? One alternative is to vendor the Another is to detect in both ghc and cabal-install if the current executable is compiled with |
@hasufell @geekosaur I give more info on the problem and outline some solutions in https://gitlab.haskell.org/ghc/ghc/-/issues/25087. It would be really nice if you could give some feedback on which solution would be preferable to the cabal maintainers. |
Describe the bug
End of log says it all:
To Reproduce
I have reproduced it two times with the following invocation:
On IntersectMBO/ouroboros-consensus@98dbae0
System information
Despite that message, it is the one installed by the command on the 3.12.0.0 release:
The text was updated successfully, but these errors were encountered: