This regularly broke things – as can be seen from the number
of packages that were opting out of it – while providing only a
dubious and partial benefit to purity that other build systems did
not “enjoy”.
It has become associated with Darwin, but was actually introduced
in 2007 as part of 67d41efde1,
a work‐in‐progress commit for KDE 4 that introduced the CMake
setup hook. It has haunted us ever since, and will presumably become
even better at doing so now that it is a dead ghost.
Of course, it is possible and even likely that more impure paths will
leak into Darwin builds from third‐party CMake modules included
in packages. However, considering it already disregarded many of the
most common macOS system paths, it will be better overall to address
these in a targeted manner than dealing with the effects of this
brute‐force hook. In the long run, a good sandbox is going to be
the solution for reliable build reproducibility on the platform.
libc++ only supports a limited range of Clang versions, so this was
relying on the LLVM version corresponding to the one used in Swift’s
fork. Since Swift builds its own LLVM 15 anyway, we can simply install
the required libc++ headers along with it.
Swift needs Clang to link with. The linker patch breaks linking
when using Swift with a GCC‐based standard environment.
Similarly, the internal Clang headers in the resource directory are
coupled to the corresponding version of Clang. The resource root patch
caused Swift’s Clang to use the resource directory from the version
of Clang used in the build environment, which is only compatible if
the versions match.
Instead, hard‐code the Clang path in the patches and wrappers.
Honestly I did this in the middle of trying things and then forgot
about it, and I just don’t feel like bootstrapping the whole thing
again to drop this commit.
https://hydra.nixos.org/build/299109156
Per the release notes: https://docs.python.org/3/whatsnew/3.13.html
> Remove the PyEval_ThreadsInitialized() function, deprecated in Python 3.9. Since Python 3.7, Py_Initialize() always creates the GIL: calling PyEval_InitThreads() does nothing and PyEval_ThreadsInitialized() always returns non-zero.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Dunno if this is correct, there's other `hostPlatform.isDarwin`
conditionals which may be wrong.
Leaving the other conditionals to swift maintainers or people who are
interested in swift cross-compilation
```
$ nix repl --file . --system aarch64-darwin
nix-repl> pkgsCross.aarch64-multiplatform.swift
«derivation /nix/store/kqbaqwdfc9g0yvkq4ffrlqspranprlmy-swift-wrapper-aarch64-unknown-linux-gnu-5.8.drv»
nix-repl> pkgsCross.aarch64-multiplatform.buildPackages.swift
error:
error: expected a string but found null: null
at /home/artturin/nixgits/my-nixpkgs/.worktree/2/pkgs/development/compilers/swift/compiler/default.nix:586:11:
585| #WATCHOS_SIMULATOR
586| }.${targetPlatform.darwinPlatform}}
| ^
587|
```
Fail to build with ninja 1.12 when NIX_BUILD_CORES is low (Hydra or Github Actions):
```
ld: warning: directory not found for option '-L/nix/store/g9rbp9m6vs1xj4jl6b6vjb6bm8kgr107-SDKs/MacOSX10.15.sdk/usr/lib/swift'
...
ld: warning: Could not find or use auto-linked library 'swiftCompatibility56'
Undefined symbols for architecture arm64:
"__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from:
__swift_FORCE_LOAD_$_swiftCompatibility56_$_Optimizer in libswiftCompilerModules-bootstrapping1.a(Optimizer.o)
...
```
Can reproduce using `nix --option cores 2 build -f . swiftPackages.swift-unwrapped`.
Until we find out the exact cause, follow [swift upstream][1], pin ninja to version
1.11.1.
[1]: https://github.com/swiftlang/swift/pull/72989
Swift releases are associated with particular Darwin SDK versions. They
don’t _have_ to use that version, but it makes sense to use that version
by default. The deployment target is set to the supported Swift minimum
versions. Unlike C and C++, Swift requires you to availability
annotations, so propagating a newer SDK should be safe.
libarclite is needed to support ARC on very old deployment targets
(10.10 and older). None of these deployment targets are supported
deployment targets in nixpkgs, especially for Swift. This removes the
need to package the command-line tools executables.
Swift’s build makes a few assumptions about how the SDK is set up that
are not true anymore with the new SDK. Fix it to find the SDK at
`$SDKROOT` and copy additional stubs it needs to bootstrap.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Since theey is not active in a long span of time.
None of the packages in this commit are orphan.
All the packages listed here are related to Swift programming language compiler
suite.
- merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git.
- remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required.
- fixes https://github.com/NixOS/nixpkgs/issues/166205
- provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548https://github.com/NixOS/nix/issues/9640
- pkgsCross.x86_64-freebsd builds work again
This change can be represented in 3 stages
1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi}
2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin}
3. remove all references to libcxxabi outside of llvm (about 58 packages modified)
### merging libcxxabi into libcxx
- take the union of the libcxxabi and libcxx cmake flags
- eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency
- libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx.
- darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient.
- linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient.
- libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+)
- git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway.
### stdenv changes
- darwin bootstrap, remove references to libcxxabi and cxxabi
- cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12)
- adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx
### 58 package updates
- remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed
- swift, nodejs_v8 remove libcxxabi references in the clang override
https://github.com/NixOS/nixpkgs/pull/292043
Without the change `swift` build fails on bundled `llvm` on
`staging-next` as:
In file included from /build/src/llvm-project/llvm/lib/Support/Signals.cpp:14:
/build/src/llvm-project/llvm/include/llvm/Support/Signals.h:119:24:
error: unknown type name 'uintptr_t'; did you mean '__intptr_t'?
void CleanupOnSignal(uintptr_t Context);
^~~~~~~~~
__intptr_t
THe change pulls in upstream fix.
The Swift compiler derivation modifies the clang wrapper to use
`exec -a "$0"` to allow it to use the same binary for both `clang` and
`clang++`. The sed script it uses to do this fails after the cc-wrapper
changes in 6f2b3ba027 were merged.
This is fixed by updating `makeClangWrapper` to work with the cc-wrapper
changes by having Bash invoke a simple script that uses `exec -a "$0"`
to set the required name for clang.
This fixes the staging-next build failures with Swift on Darwin and Linux.
https://github.com/NixOS/nixpkgs/pull/248496#issuecomment-1676831102
`BOOTSTRAPPING-WITH-HOSTLIBS` is also what official builds use on
Darwin. It's unclear why `BOOTSTRAPPING` was working before, but it is
probably not supported on Darwin to begin with. It was now causing
crashes because of mixing of two copies of stdlib at run-time.
