clang_15 appears to not cross compile in the build!=(host==target)
case due to two problems, which this commit fixes:
- It trips -Wmaybe-uninitialized on recent gcc, but only in the
build!=host case (likely due to #ifdefs)
- Two more buildPlatform tools have been added:
clang-tidy-confusable-chars-gen and clang-pseudo-gen
Co-authored-by: Rahul Butani <rrbutani@users.noreply.github.com>
bumping `llvmPackages_git` to match `llvmPackages_15`; this will let us
continuing bringing `llvmPackages_git` to parity with `llvmPackages_15`
without needing to invest time and effort into getting the current
llvmPackages_git's commit's test suite to pass under all the platforms,
etc.
this will also allow us to begin diffing derivations between
`llvmPackages_15` and `llvmPackages_git` as a way of tracking down
remaining differences between the package sets
Port of bc4dbee115 ("llvmPackages_15:
updates for LLVM 15").
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:
4f827318e3/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: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r990267037
Co-authored-by: Bernardo Meurer <bernardo@meurer.org>
Port of c7231c0b6d ("llvmPackages_15.llvm: run the tests on macOS").
The sysctl native check input was taken from
6d0c87602f ("llvmPackages_15.llvm: add in a missing check dep"),
because it looks like it was supposed to be part of c7231c0b6d
instead.
Port of 6d0c87602f ("llvmPackages_15.llvm: add in a missing check
dep").
I did not include the sysctl nativeCheckInputs change from that
commit, as it looks like it was included by mistake and was supposed
to be in c7231c0b6d ("llvmPackages_15.llvm: run the tests on macOS").
I've also included the doCheck default from that commit (without the
change to run on non-Linux), as 6d0c87602f just set it to true.
Port of 404ef6b6c9 ("llvmPackages_15.clang: drop the C++ std version
`-DCMAKE_CXX_FLAG`"). The commit mentioned as removing the need for
the override[1] first appeared in LLVM 10.
[1]: 2724d9e129
Port of 2a58596dd2 ("llvmPackages_15.llvm: enable polly by default").
It should be ported all the back to LLVM 12, but I haven't done that
here because going further back than 14 requires fixing patches, and
I'm focused on my goal of getting the delta between LLVM 15 and LLVM
git under control — it's going to be hard enough to accomplish that.
compiler-rt has accumulated several regressions that prevent it from building
on ARMv6. It is important to note that there are two major versions of ARMv6:
base ARMv6 and ARMv6K. ARMv6K includes several important new instructions,
such as non-word size atomic operations (ldrexd, strexd, etc.) and the yield
instruction. Most ARMv6 CPUs actually implement ARMv6K, including all those used
in Raspberry Pis, but nixpkgs' "raspberryPi" platform targets base ARMv6.
compiler-rt versions 8-14 fail to build on ARMv6 and ARMv6K. compiler-rt 15 (not
yet in nixpkgs) builds on ARMv6K but not ARMv6. This patch fixes versions 9-14
on both ARMv6 variants. The patches don't apply cleanly to version 8, and I
figured it wasn't worth carrying another version of the patches for such an old
version.
A total of five patches are required to get compiler-rt building on ARMv6:
* armv6-mcr-dmb.patch: use `mcr` to provide the equivalent of `dmb` on ARMv6.
Included in LLVM 15.
* armv6-sync-ops-no-thumb.patch: prevent certain atomic operation functions
from using Thumb mode. Included in LLVM 15.
* armv6-no-ldrexd-strexd.patch: don't use ldrexd or strexd, which are not
available in base ARMv6. Submitted upstream by me.
* armv6-scudo-no-yield.patch: use nop instead of yield on ARMv6 in standalone
scudo. Required by versions >=13, since they enable standalone scudo.
Submitted upstream by me.
* armv6-scudo-libatomic.patch: link standlone scudo to libatomic on ARMv6 (and
any other platforms that need it). Not yet submitted because the backport is
a bit different from the upstream version and I need to test it.
This was added in 00839fea22 ("llvmPackages_15.compiler-rt: fixes for Darwin"),
which says:
> this introduces a codesigning related patch that we can drop once
> #195107 goes through
The referenced PR ("sigtool: 0.1.2 → 0.1.3") has now been merged, so
I'm dropping the patch as instructed.
The effect of `.out // { outputSpecified = false; }` in these cases
is to select the default output explicitly, but then make the
selection implicit until `overrideAttrs` is called. Previously
`overrideAttrs` would not preserve output selection, masking the
apparently unnecessary behavior of this workaround.
For `libllvm-polly`, this logic does not apply, as it does not
select the default output.
The `outputSpecified` workaround was introduced in
https://github.com/NixOS/nixpkgs/pull/122554
and was perhaps rushed because of a release deadline, and expected
delays from mass rebuilds.
The change in `overrideAttrs` behavior was added in
5b2f597b11 / https://github.com/NixOS/nixpkgs/pull/211685
and the problem was discovered in https://github.com/NixOS/nixpkgs/pull/218537,
which may contain further information.
Port of 44165d3657 ("llvmPackages_{14, git}.clang: add nostdlibinc flag")
to Clang 15. It was originally thought this wasn't needed[1], but it is,
to fix expressions like the following:
with import ./. {};
llvmPackages_15.libcxxStdenv.mkDerivation {
name = "libcxx-stdenv-c++-test";
dontUnpack = true;
input = ''
#include <cstdlib>
int main() {
std::abort();
return 0;
}
'';
passAsFile = [ "input" ];
installPhase = ''
$CXX -c -o $out -x c++ $inputPath
'';
}
[1]: https://github.com/NixOS/nixpkgs/pull/194634#issue-1398202534
This reverts commit 386aba3115.
As I understand it from reading
<https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>,
the structure of LLVM licensing is as follows:
- They're in the process of relicensing to Apache-2.0 WITH LLVM-exception,
but they haven't got permission to relicense all the code yet.
This means that some of the code can be used under the new license,
but not all of it, and it's difficult to know which is which. This
license is therefore probably not useful yet, until the relicensing
effort is commit.
- While the relicensing effort is ongoing, code being contributed to
LLVM has to have permission to be used under the old and new
licensing schemes. Since the new licensing scheme can't be used
for all code yet, it only makes sense to use LLVM's code under the
old licensing scheme at the moment.
- The old licensing scheme is that code for the LLVM components we
care about is all available under the NCSA license, and some
components are optionally available under a different license,
usually the MIT license, instead.
So I think we should go back to just listing NCSA, or NCSA/MIT, and
forget about the new license until it actually becomes useful,
i.e. LLVM's relicensing effort is complete.
LLVM-exception only makes sense when used with the Apache 2.0 license,
so let's combine them, so it's not possible to forget one of them like
happened with llvm_15.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
I got the plugin API support at least once incorrect. Instead of
copying the deifnition let's consolidate it within binutils itself.
While at it forward-ported changes to llvm_{13,14,15}.
The change is a no-op from rebuild perspective.
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
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: #211340
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
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.
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)
This restores this check to what it originally was in #196909 (see:
https://github.com/NixOS/nixpkgs/pull/196909#discussion_r1000536298) 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`).
