The derivation’s `name` attr is already openshadinglanguage, and that is
what it is referred to as upstream.
Remove unneeded `libsForQt5`—not clear why this was here, this drv does
not use Qt.
LLVM stdenvs lack a set of `__atomic_*` routines that compilers
sometimes rely on, making it impossible to build certain C programs in
them. The reason we lack these routines is that we're using neither
compiler-rt's implementation of them (which was disabled by default a
long time ago) nor gcc's implementation (libatomic). See #391740 for a
more detailed explanation and an example of program that cannot be built.
Since no particular preference was expressed as to which approach
should be used to solve this, I'm going with LLVM's implementation
and recommended setup, which seems to be used also in AIX, Fuchsia
and Apple platforms. This consists of enabling a CMake flag,
`COMPILER_RT_BUILD_STANDALONE_LIBATOMIC`, which causes the routines to
be built and shipped in a separate DSO (placing them in a DSO instead
of `builtins.a` is needed for correctness, as it ensures the lock
section is unique in memory).
As with the other builtins, I'm symlinking this DSO to `libatomic.so` so
that downstream packages don't need specific/complicated logic for LLVM.
Other details:
- For static platforms, since no dynamic linking is expected at all, it
should be correct to ship the symbols in `builtins.a`.
So, that's what I'm doing in those cases.
- Since v19, compiler-rt allows using pthread locks rather than ad-hoc
ones for the atomic routines. Since this plays better with
instrumentation, I'm enabling this whenever libc is available.
- It would be nice to put the DSO in a separate output / derivation, so
that the rest of compiler-rt isn't pulled into the runtime closure,
but it isn't high prio since compiler-rt doesn't pull in dependencies
other than libc, libc++ and unwinder.
Fixes: https://github.com/NixOS/nixpkgs/issues/311930
This allows users to put zig in their `mkShell` without ending up with a
ZIG_GLOBAL_CACHE_DIR value set that points back to a location that only
would exist in the sandbox.
The default GCC compiler in Nixpkgs was recently changed, bringing in a
new default C standard (gnu23), which GHC's C backend is not compatible
with.
This fix adds a flag to force GCC to use an older compatible C standard.
some of these were just typos like `finalAttr`, `finalAtts` or `finaAttrs`
some of these were using `self`, `final`, `finalPackage`, `attrs` or `_`
some of these were wrong by using `oldAttrs` or `finalPackages`
other than the nixos manual this shouldn't create any rebuilds
