AdrianVovk opened a new issue #1525: URL: https://github.com/apache/buildstream/issues/1525
I'm aware of #1418, but I'm opening this as a separate issue for a couple of reasons: 1. To increase visibility for anyone who will inevitably run into this issue (i.e. the freedesktop-sdk team) 2. That PR is stale; it hasn't been interacted with in over a year 3. I don't know if the appropriate people would get a notification if I left a comment there due to the Gitlab->Github transition As of glibc 2.34, /dev/shm is required for sem_open and other shm-dependent functions. Previously, glibc would fall back to non-standard locations, but it no longer does so. From the [changelog](https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html): > * On Linux, the shm_open, sem_open, and related functions now expect the file shared memory file system to be mounted at /dev/shm. These functions no longer search among the system's mount points for a suitable replacement if /dev/shm is not available. So, in Buildstream's environment where /dev/shm doesn't exist, upgrading to glibc 2.34 is a breaking change. In my project, this manifests itself in total build failure: Python's `configure` checks that `sem_open` works, and finds that it doesn't (whereas before it did). From there, Python is built without the `multiprocessing.synchronize` library, and then build tools that depend on this library fail to run. One of these tools is Firefox's mach, so I can't build mozjs or anything that depends on it. You get the picture. My options, as a user of BuildStream, are to downgrade glibc to 2.33 and stay on an old C library until Buildstream fixes this, or upgrade to the unstable/WIP BuildStream 2. For now, I'm downgrading to glibc 2.33 and I'm hoping this issue will get resolved in BuildStream quickly (and put into a release) so I can continue to keep my system up-to-date and secure. I think BuildStream should create /dev/shm by default. As-is, BuildStream is not a correctly-configured build environment, and /dev/shm missing causes build failures. Yes, this is technically a backward-incompatible change. However, the status-quo is that shm-related functions all work. If Buildstream adds in /dev/shm before other projects start depending on glibc 2.34, shm-related functions will continue to work. If Buildstream doesn't add this, these functions will suddenly *stop* working Moreover, I don't think I've ever upgraded Buildstream without subsequently rebuilding the system. If you don't want to introduce a backwards-incompatible change nonetheless, I think there should be at least a project-wide switch to enable it. Or, give a configuration option to each of the default build plugins (meson, autotools, cmake, etc) and then each project could enable it under `elements` in project.conf. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
