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.
We already did this for -march in 12b0e8ac74 ("clang: don't set
-march for overridden target"), but it should have been done for all
machine flags, for the same reason.
Example bug this fixes:
nix-shell -E '
with import ./. {
crossSystem = {
system = "powerpc64le-linux";
gcc.cpu = "power10";
};
};
clangStdenv.mkDerivation { name = "test"; }
' --run '$CC -target wasm32-unknown-unknown -c /dev/null'
Which previously failed with:
clang: error: unsupported option '-mcpu=' for target 'wasm32-unknown-unknown'
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
swiftc uses cc-wrapper which sets the -march flag on some systems which
breaks the build. This change adds a flag, disableMarch, to cc-wrapper
which disables using the -march flag.
https://github.com/NixOS/nixpkgs/issues/295322
- 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
Failing Hydra build: https://hydra.nixos.org/build/249763077/nixlog/12
The problem is that glibc commit
64b1a44183a3094672ed304532bedb9acc707554 marked the `FILE*` argument of a few
functions including `fread` & `ferror` as non-null. The applied patch
("Android: add better nullability checks for nullability annotations added in NDK 26")
is targeted for the Android platform, but fixes said issue as well: the
handle returned from `fopen` is of type `Optional<T>` and the `guard`
expression unwraps that now (and throws an exception if `nil` is
returned). The previous `nil`-check didn't modify the type of `fp`, but
only raised the exception and moved on with `Optional<T>`.
It's a little sad that the patch needs to be applied at so many places,
but I guess that's what you get with language-level package managers 🤷
Also, seems good-enough to me given that it's actually temporary, the
patch is already upstream and will probably be obsolete at one of the
next Swift updates.
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
Swift uses libc++ 15, but it should really be using the same libc++ from
the stdenv. While not strictly needed currently, Swift 5.9 will support
C++ interop. If Swift is not using the stdenv C++, any C++ library used
with interop would need to be rebuilt against the Swift libc++.
