Originally reported on https://github.com/haskell/cabal/issues/9993 `semaphore-compat` provides an implementation of semaphores based on the system libc library. However, semaphore implementations provided by different libc implementations (for example musl and glibc) may not be compatible with each other. This is not just limited to how the semaphore files are named, as suggested on the original ticket, but even the underlying implementations of the semaphore data structure can be incompatible with each other. This manifests when we have `ghc` and `cabal` compiled with different libc implementations, as in the linked ticket when cabal is statically linked against `musl` but `ghc` is dynamically linked against the system provided `glibc`. Here are some possible solutions: 1. Vendor a semaphore implementation into `semaphore-compat` 2. Add an executable to the ghc suite or a mode to the compiler that is responsible for creating and waiting on the semaphore. Cabal will call this executable instead of using a linked semaphore implementation 3. Explicitly require build tools and ghc are linked against the same libc if `-jsem` is in use 4. Replace the semaphore implementation with one not based on shared memory structures, like one that uses unix sockets instead. What do we do with earlier versions of `ghc` which use the system implementation? Does cabal-install need to disallow using `--semaphore` with these versions? If we choose option 1 and we want `cabal-install` to continue to work with existing versions of ghc linking against system libc, then cabal-install needs to link against both the system semaphore implementation and the vendored implementation and use the appropriate function to create the semaphore depending on the version of GHC. Similarly with 2, `cabal-install` needs to still link against the system implementation until support for such GHC versions is deprecated.