llvmPackages_15: init at `15.0.7` #194634

See NixOS#194634 for details. PRs: - NixOS#191372 - NixOS#190936 - NixOS#82131 - NixOS#199844 - NixOS#197674 - NixOS#184408 - NixOS#193004

See NixOS#194634 (comment) for details. PRs: - NixOS#211401 - NixOS#211161 - NixOS#206742 - NixOS#211687

@lovesegfault

None of the patches required any touch-up; the only change of note is: - due to changes in the libc++/libc++abi build (https://reviews.llvm.org/D120719 and https://reviews.llvm.org/D131037) we have to add an extra build option to the libc++ header only build that sidesteps bits of the libc++ build config that assume libc++-abi is present in the build: https://github.com/llvm/llvm-project/blob/4f827318e3e8ccab4ff131e06234caa827e91e4e/libcxx/src/CMakeLists.txt#L255-L256 Rather than maintaining a precise set of build options that let us dodge referencing libc++-abi variables in the libc++ header only build, we set `LIBCXX_CXX_ABI` to `none`, as suggested by @lovesegfault. More discussion about this here: NixOS#194634 (comment) Co-authored-by: Bernardo Meurer <bernardo@meurer.org>

`llvmPackages_15` originates from `llvmPackages_git` which does not include this change

See the comments here for context: NixOS#194634 (comment) Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>

libc++ has switched to using `__attribute__((using_if_exists))` to handle incomplete libc implementations; see: llvm/llvm-project@a9c9183 These essentially require a modern C++ compiler (clang gained support in LLVM 13: llvm/llvm-project@369c648, gcc appears to not have support yet: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105584). Previously this was not an issue for us (despite the transition happening around LLVM 13) but something about the changes to the libc++/libc++-abi build has made it so that on platforms with incomplete libc impls (i.e. Darwin is missing `quick_exit`/`at_quick_exit`) we error during the `libcxx-abi` build when the stdenv's (older, not supporting `using_if_exists`) compiler tries to import libc symbols that aren't present. The libc++ docs suggest we use a modern compiler to build libc++ anyways (https://releases.llvm.org/15.0.0/projects/libcxx/docs/index.html#platform-and-compiler-support) so this commit uses stdenv's containing the package set's clang to build libcxx/libcxx-abi. This is similar to how libc++ bootstrapping builds (https://releases.llvm.org/15.0.0/projects/libcxx/docs/BuildingLibcxx.html#bootstrapping-build) work.

… LLVM stdenv

this introduces a codesigning related patch that we can drop once NixOS#195107 goes through see: NixOS#194634 (comment)

see the discussion here for context: NixOS#194634 (comment)

…= "glibc"` This restores this check to what it originally was in NixOS#196909 (see: NixOS#196909 (comment)) and lets `compiler-rt` eval successfully when trying to compile the `llvmPackages_15` set for mingw targets (i.e. a platform that *is* GNU but does *not* use glibc). --- It's not clear to me what the `haveLibc` check is doing here (platforms that seem to use glibc like `x86_64-linux` and have `plat.libc == "glibc"` have `haveLibc = false` because `stdenv.cc.libc` is `null`).

See: NixOS#194634 (comment)

as detailed within, adding `asm/ptrace.h` leads to `asm/ptrace-abi.h` being included which defines preprocessor symbols that clash with identifiers used in the LLVM headers (`FS` and `CS` only defined on i686)

…nfigure time this previously worked because, when using Make, this variable was expanded at build time

this comment has a more complete history: NixOS#194634 (comment) in short: polly was disabled in the llvm 11 -> llvm 12 copy, mostly by accident most of the Polly install dirs patch has been upstreamed; one change remains

there are a few parts to this: - adding darwin specific check deps - working around referencing LLVM dylibs during the checkPhase in a way that supports darwin + previously we just set `$LD_LIBRARY_PATH` and/or made some strategic symlinks + now we have LLVM's `lit` config set the appropriate env vars as needed (as is done for other LLVM subprojects) + in retrospect switching to `installCheckPhase` might have been the better move.. - patching `lit` to deal with `$DYLD_LIBRARY_PATH` being purged for new "protected" processes more details within.

Details within but ultimately there isn't a satisfying resolution for any of the three test failures we were seeing and all three deserve further exploration. For the `sw_vers` macOS version issue in particular, it's possible to observe the nixpkgs provided `CoreFoundation` vs system `CoreFoundation` for `x86_64` and `aarch64` like so (on a host running macOS `13.0.1`): ```console $ nix-shell -p darwin.DarwinTools --system aarch64-darwin --command "sw_vers" ProductName: macOS ProductVersion: 13.0.1 BuildVersion: 22A400 $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command "sw_vers" ProductName: Mac OS X ProductVersion: 10.16 BuildVersion: 22A400 ``` Where `/System/Library/CoreServices/SystemVersion.plist` has: ```console $ cat /System/Library/CoreServices/SystemVersion.plist | grep ProductVersion -A 1 <key>ProductVersion</key> <string>13.0.1</string> ``` Further: ```console $ nix-shell -p darwin.DarwinTools --system aarch64-darwin --command 'otool -L $(which sw_vers)' /nix/store/nb2q33ak2zif49ndcpc6m823z0vhmy8y-DarwinTools-1/bin/sw_vers: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'otool -L $(which sw_vers)' /nix/store/88v4kjvgwl71byfpvd0baviiq7l5appc-DarwinTools-1/bin/sw_vers: @rpath/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1454.90.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) ``` For the `x86_64` `sw_vers` binary we can see rpath: ```console $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'otool -l $(which sw_vers)' | grep LC_RPATH -A 2 -B 1 Load command 13 cmd LC_RPATH cmdsize 120 path /nix/store/zvr4wypbgskhhw9cawfn7mmxfa75nh8f-swift-corefoundation-unstable-2018-09-14/Library/Frameworks (offset 12) ``` And we can confirm that the nixpkgs provided `CoreFoundation` is what ultimately gets loaded: ```console $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'DYLD_PRINT_LIBRARIES=1 sw_vers' dyld[16215]: <no uuid> /nix/store/88v4kjvgwl71byfpvd0baviiq7l5appc-DarwinTools-1/bin/sw_vers dyld[16215]: <no uuid> /nix/store/zvr4wypbgskhhw9cawfn7mmxfa75nh8f-swift-corefoundation-unstable-2018-09-14/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation dyld[16215]: <no uuid> /nix/store/xd2a4xh8kdwq0j67hzgw720npdw5hzkk-ICU-66108/lib/libicucore.A.dylib <snipped> ``` ```bash nix-diff \ $(nix path-info nixpkgs#legacyPackages.aarch64-darwin.darwin.DarwinTools --derivation) \ $(nix path-info nixpkgs#legacyPackages.x86_64-darwin.darwin.DarwinTools --derivation) ``` doesn't show any _obvious_ discrepancies

see this thread for context: NixOS#194634 (comment) Co-authored-by: misuzu <bakalolka@gmail.com>

…lation The two scenarios described within where splicing doesn't handle selecting the right package for us are observable in the following (nix repl session): ``` > np = import <nixpkgs> { system = "x86_64-linux"; crossSystem = { config = "aarch64-linux"; }; } > np.__splicedPackages.hello ? __spliced true > np.__splicedPackages.python3Packages.psutil ? __spliced true > np.__splicedPackages.python3.pkgs.psutil ? __spliced false > (np.__splicedPackages.python3.withPackages (ps: with ps; [psutil])) ? __spliced false ``` See: NixOS#211340

Context: NixOS#194634 (comment)

the tests still don't all pass so `doCheck` is still disabled

Context: NixOS#194634 (comment) All the subprojects seem to be uniformly licensed under NCSA and the LLVM license now (with the exception of openmp which has an additional Intel license that doesn't seem to be in SPDX?); see: - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/compiler-rt/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/libcxx/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/libcxxabi/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/openmp/LICENSE.TXT

this is in preparation for the next commit which exposes the release information and monorepo source as overridable args (which makes it easier for users to use their own LLVM in nixpkgs) this commit only adds a check in the `llvm` package's postConfigure that makes sure the LLVM source provided matches the version we were given; the actual machinery (functionally just a cosmetic change; causes no rebuilds) is in the next commit

…s overridable args this makes it easier for users to use their own LLVM in nixpkgs

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

llvmPackages_15: init at `15.0.7` #194634

llvmPackages_15: init at `15.0.7` #194634

Commits on Jan 27, 2023

llvmPackages_15: init at 15.0.7 #194634

llvmPackages_15: init at 15.0.7 #194634

Commits on Jan 27, 2023

llvmPackages_15: init at `15.0.7` #194634

llvmPackages_15: init at `15.0.7` #194634