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++.
`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.
