compiler-rt: enable build of libatomic#398520
compiler-rt: enable build of libatomic#398520mildsunrise wants to merge 1 commit intoNixOS:masterfrom
Conversation
|
Looks like this could go straight to master? |
ea89c19 to
0d7159d
Compare
|
ah, you're right... I'm so used to my changes causing mass rebuilds :_ I'll change that and also rewrite the cmake options a bit so that we don't pass them in case of older versions that don't have them |
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 NixOS#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: NixOS#311930
0d7159d to
7582576
Compare
| [ (lib.cmakeBool "COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN" (!withAtomicsLib)) ] | ||
| ++ lib.optional withAtomicsLib (lib.cmakeBool "COMPILER_RT_BUILD_STANDALONE_LIBATOMIC" true) | ||
| ++ lib.optional withAtomicsPthread (lib.cmakeBool "COMPILER_RT_LIBATOMIC_USE_PTHREAD" true) |
There was a problem hiding this comment.
| [ (lib.cmakeBool "COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN" (!withAtomicsLib)) ] | |
| ++ lib.optional withAtomicsLib (lib.cmakeBool "COMPILER_RT_BUILD_STANDALONE_LIBATOMIC" true) | |
| ++ lib.optional withAtomicsPthread (lib.cmakeBool "COMPILER_RT_LIBATOMIC_USE_PTHREAD" true) | |
| [ | |
| (lib.cmakeBool "COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN" (!withAtomicsLib)) | |
| (lib.cmakeBool "COMPILER_RT_BUILD_STANDALONE_LIBATOMIC" withAtomicsLib) | |
| (lib.cmakeBool "COMPILER_RT_LIBATOMIC_USE_PTHREAD" withAtomicsPthread) | |
| ] |
There was a problem hiding this comment.
that's how it was in the previous version (0d7159d). I changed it to avoid passing unknown CMake options to old LLVM versions that don't support them
There was a problem hiding this comment.
We always could use lib.versionAtLeast. With the new refactoring, we tried to get less optionals here.
There was a problem hiding this comment.
versionAtLeast is being used already, see the default values of the fields. I can move it here if desired (which I agree is more explicit, but less true to the user's intent IMO... I'd prefer things to fail if user requests standalone atomics in a version that doesn't have them)
regardless of whether versionAtLeast is used here or in the defaults, we still need the optionals right? COMPILER_RT_BUILD_STANDALONE_LIBATOMIC was introduced in v13 and COMPILER_RT_LIBATOMIC_USE_PTHREAD was introduced in v19
There was a problem hiding this comment.
Should be fine for at least COMPILER_RT_BUILD_STANDALONE_LIBATOMIC since only 1 thing uses LLVM 12
There was a problem hiding this comment.
LLVM 12 is no more in nixpkgs, and only 18 does not support COMPILER_RT_LIBATOMIC_USE_PTHREAD. Passing that option unconditionally should not affect the build output, so using the simpler code makes sense to me.
| # since that's when the standalone build became available; GCC's | ||
| # libatomic should be used in other cases. | ||
| withAtomics ? | ||
| (stdenv.hostPlatform.useLLVM or false) |
There was a problem hiding this comment.
We don't need the or false since lib/systems/default.nix adds it in.
There was a problem hiding this comment.
ah, good to know. we do stdenv.hostPlatform.useLLVM or false everywhere in this file so I assumed I was missing something
|
I still think this is a good idea. Can I do anything to help? |
|
Open a new PR with the comments addressed and the merge conflict fixed? |
|
@tobim thanks for taking over this! |
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, this PR goes 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 ofbuiltins.ais needed for correctness, as it ensures the lock section is unique in memory).As with other builtins, I'm symlinking this DSO to
libatomic.soso that downstream packages don't need specific/complicated logic for LLVM.Other details:
builtins.a. So, that's what I'm doing in those cases.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.