In https://gcc.gnu.org/PR103598 we found out that gcc-12
changed __PRETTY_FUNCTION__ slightly and broke llvm-12 (and older)
tests that rely on exact type match. llvm-13 already removed the
qualified names from the expected output.
This change changes expected output to avoid llvm:: namespace prefix.
This is enough to get tests pass on x86_64 again.
Tested against this week's gcc-12 and against gcc-10.
Without the fix build fails on gcc-12 as:
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:
In member function 'std::string llvm::NVPTXAsmPrinter::getPTXFundamentalTypeStr(...':
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1319:10:
error: use of deleted function 'std::__cxx11::basic_string<...>; std::nullptr_t = std::nullptr_t]'
1319 | return nullptr;
| ^~~~~~~
The patch is present in upstream releases since llvm-12.
Commit 199b7c50 "compiler-rt: remove <cyclades.h> from libsanitizer"
broke conditional conditional musl patches.
The change has a few effects:
- pkgsStatic.llvmPackages_{5,6,7}.compiler-rt: fix build on musl after cyclades backport
- pkgsStatic.llvmPackages_{{5..13},git}.compiler-rt: drop incomplete musl patches as
sanitizers are disabled anyway and require more upstream porting.
the fix to extendDerivation in #140051 unwittingly worsened eval performance by
quite a bit. set elements alone needed over 1GB extra after the change, which
seems disproportionate to how small it was. if we flip the logic used to
determine which outputs to install around and keep a "this one exactly" flag in
the specific outputs instead of a "all of them" in the root we can avoid most
of that cost.
linux-headers-5.13 removed <cyclades.h> along with device support.
Backport a single https://reviews.llvm.org/D102059 upstream change to
fix compiler-rt build.
Use local patches as there is a whitespace change compared to upstream.
When using GNU binutils, clang passes the LLVMgold.so plugin to the
linker for certain operations that require special support in the linker
like doing link time optimization (LTO). When passing the plugin to the
linker's command line, clang assumes that llvm and itself are installed
in the same prefix and thus `/path/to/clang/bin/../lib/LLVMgold.so` is
the plugin.
Since we install clang and llvm to separate store paths, this assumption
does not hold. When clang-unwrapped only had a single output, we worked
around this issue by symlinking `$out/lib/LLVMgold.so` to
`${llvm}/lib/LLVMgold.so`. However since we split all llvm packages into
multiple outputs clang's `$out` no longer has a lib directory and clang
can't discover clangs lib output on its own. As a result LTO was broken.
Instead of introducing yet another hack and having a symlink to
LLVMgold.so in `$out/lib` (despite having `$lib/lib` as well), we patch
clang to use a hard coded path to `${libllvm.lib}/lib` for discovering
`LLVMgold.so`.
Resolves#123361.
The main thing was using `llvm_meta` in all versions.
Secondarily:
- libunwindx7: Forgot to split outputs
- libcxx{,abi} 12: Forgot to apply output-splitting patches.
- simplify `useLLVM` stdenv-switching logic.
- openmp always gets its own directory
In 7869d16545 I got rid of the symlinking
by forcing `COMPILER_RT_OS_DIR` to always be the empty string. I thought
this was good because it just make compiler-rt be installed in a normal
way.
However, various LLVM tools expect the `COMPILER_RT_OS_DIR` to be set
normally, and fail to find things when they aren't in the expected lib
subdir.
Maybe it would be best to patch that too in the long term, but for now
we just undo this change.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
This patches are included from libcxx and libcxxabi when
stdenv.hostPlatform.isMusl. After #117433 the patchs to that patch
wasn't adjusted for the new structure, likely because it doesn't come up
during normal eval. This fixes (among other attribute paths):
* pkgsMusl.llvmPackages_12.libcxxabi
* pkgsMusl.llvmPackages_12.libcxx
* pkgsMusl.llvmPackages_11.libcxxabi
* pkgsMusl.llvmPackages_11.libcxx
* pkgsMusl.llvmPackages_10.libcxxabi
* pkgsMusl.llvmPackages_10.libcxx
* pkgsMusl.llvmPackages_9.libcxxabi
* pkgsMusl.llvmPackages_9.libcxx
* pkgsMusl.llvmPackages_8.libcxxabi
* pkgsMusl.llvmPackages_8.libcxx
* pkgsMusl.llvmPackages_7.libcxxabi
* pkgsMusl.llvmPackages_7.libcxx
* pkgsMusl.llvmPackages_6.libcxxabi
* pkgsMusl.llvmPackages_6.libcxx
* pkgsMusl.llvmPackages_5.libcxxabi
* pkgsMusl.llvmPackages_5.libcxx
Only evaluation was tested, not compilation though.
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
