See: https://github.com/NixOS/nixpkgs/pull/246577/files#r1600650238
This code was breaking some thing for me, and I believe it was a
mistake. I hink we *do* wanna link libc, since libc++ depends on it, but
*don't* want to link an already-existing C++ standard library
implementation. `-nostdlib++` without `-nostdlib` therefore seems
correct to me.
Without this change, we do indeed fail to link OpenBSD.
Key test case: nixpkgs#pkgsStatic.pkgsLLVM.ncurses
Prior to this patch, this fails with errors such as:
```
error: undefined symbol: __cxa_throw
```
I think this is a reasonable solution because in #292043, libcxxabi was
'merged into libcxx', however, the commit message suggests that only
dynamic linking was accounted for, because it says:
```
* linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient.
```
Whereas, I found that if I tried linking a "hello world" C++ program
with a static hostPlatform, it failed unless -lc++abi was passed.
Signed-off-by: Peter Waller <p@pwaller.net>
LLDB expects to find the location of `bin` relative to `lib`. Patching
it to know the location would cause a cycle between the `out` output and
the `lib` output, so combine the two on Darwin.
Fixes https://github.com/NixOS/nixpkgs/issues/252838.
As noted in 3e8355df84, this seems to be
unproblematic. If we keep this disabled, it is unfortunately not
possible to do PGO with the default clang stdenv on GNU platforms.
Clang assumes that `libLTO.dylib` is located at `../lib` in the same
prefix as `clang`, but that’s not true in nixpkgs. `libLTO.dylib` is
actually located at `libllvm^lib/lib.libLTO.dylib`.
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.
Before the change `llvmPackages.bintools.bintools.targetPrefix` was not
present. This exposed as a discrepansy between `binutils` and `llvm`:
`binutils`:
nix-repl> stdenv.cc.bintools.bintools.targetPrefix
""
nix-repl> stdenv.cc.bintools.targetPrefix
""
`llvm`:
nix-repl> pkgsLLVM.stdenv.cc.bintools.targetPrefix
"x86_64-unknown-linux-gnu-"
nix-repl> pkgsLLVM.stdenv.cc.bintools.bintools.targetPrefix
error:
error: attribute 'targetPrefix' missing
As a result some attributes like `pkgsLLVM.actionlint` failed to
evaluate:
$ nix build --no-link -f. pkgsLLVM.actionlint
...
error: attribute 'targetPrefix' missing
at pkgs/development/compilers/ghc/9.4.8.nix:232:46:
231| export READELF="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}readelf"
232| export STRIP="${bintoolsFor.strip}/bin/${bintoolsFor.strip.targetPrefix}strip"
| ^
The change exposes binary prefix the same way as `binutils` does.
It appears that LLVM's build system no longer sets the executable's
rpath to include the faux resource root we pass in, so we need to make
sure cc-wrapper does this.
