In https://github.com/NixOS/nixpkgs/pull/211126 I simplified `binutils`
and `libbfd` derivations to follow upstream binutils build system
closer. As a result of `./configure --target=wasm32-unknown-wasi`
`binutils` does not install plugin headers by default.
This causes `pkgsCross.wasi32.llvm_12` (used by `firefox`) to fail the
build as:
[ 81%] Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o
/build/llvm/tools/gold/gold-plugin.cpp:38:10: fatal error:
plugin-api.h: No such file or directory
38 | #include <plugin-api.h>
| ^~~~~~~~~~~~~~
The change accomodates this constraint to disable plugin support for
`wasi` targets.
"llvm-as is an LLVM IR -> LLVM bitcode assembler not a system
assembler"[1], and therefore should not be linked as "as".
The "as" symlink was removed in 46e5ea5af6 ("llvm*: remove symlinks
to llvm-diff, llvm-as and associated LLVM IR utilities."), but that
was partially reverted by b331c72f03 ("llvm: setup some symlinks for
compatibility with binutils"), which restored a bunch of symlinks that
were incorrectly removed, but also incorrectly restored "as". This
was pointed out[2] at the time but apparently never fixed.
[1]: https://github.com/NixOS/nixpkgs/issues/93523#issue-661663683
[2]: b331c72f03 (commitcomment-40981705)
We were missing symlinks for some programs e.g. strings, which caused
e.g. pkgsLLVM.x264 to fail to build.
Here, I have filled in all the symlinks that LLVM would create if
built with the LLVM_INSTALL_BINUTILS_SYMLINKS option. Where an
existing symlink's target has changed, it's to avoid a double
indirection e.g. strip -> llvm-strip -> llvm-objcopy has because just
strip -> llvm-objcopy.
There's also the related problem that we are creating a as -> llvm-as
symlink, which doesn't make sense, but I'll remove that in a
subsequent commit so that if it somehow breaks something it's easy to
revert just that change.
Fixes: https://github.com/NixOS/nixpkgs/pull/210983
Done with the help of https://github.com/Mindavi/nixpkgs-mark-broken
Tool is still WIP but this is one of the first results.
I manually audited the results and removed some results that were not valid.
Note that some of these packages maybe should have more constrained platforms set
instead of broken set, but I think not being perfectly correct is better than
just keep trying to build all these things and never succeeding.
Some observations:
- Some darwin builds require XCode tools
- aarch64-linux builds sometimes suffer from using gcc9
- gcc9 is getting older and misses some new libraries/features
- Sometimes tools try to do system detection or expect some explicit settings for
platforms that are not x86_64-linux
hip: use finalAttrs
rocm-llvm: use finalAttrs
clang-ocl: use finalAttrs
composable_kernel: use finalAttrs
hipcub: use finalAttrs
hipsparse: use finalAttrs
miopengemm: use finalAttrs
rccl: use finalAttrs
rocblas: use finalAttrs
rocclr: use finalAttrs
rocfft: use finalAttrs
rocm-comgr: use finalAttrs
rocm-device-libs: use finalAttrs
rocm-opencl-runtime: use finalAttrs
rocm-runtime: use finalAttrs
rocm-thunk: use finalAttrs
rocmlir: use finalAttrs
rocprim: use finalAttrs
rocsparse: use finalAttrs
rocthrust: use finalAttrs
rocm-cmake: use finalAttrs
rocminfo: use finalAttrs
rocm-smi: use finalAttrs
rocclr: change maintainers to rocm team + old
rocm-comgr: change maintainers to rocm team + old
rocm-device-libs: change maintainers to rocm team + old
rocm-opencl-runtime: change maintainers to rocm team + old
rocm-runtime: change maintainers to rocm team + old
rocm-thunk: change maintainers to rocm team + old
rocminfo: change maintainers to rocm team + old
rocm-smi: change maintainers to rocm team + old
rocm-llvm: change maintainers to rocm team + old
hip: change maintainers to rocm team + old
Same adjustment as made for libc++abi in #185766, for the same reason:
the unamended dylib links to the libc++abi in the build stdenv, which
is the wrong version.
Tested on Darwin with LLVM 14 stdenv, but the phase is added to all
versions, including 11 - so this will cause a mass rebuild.
See: https://github.com/NixOS/nixpkgs/pull/185766
This reverts commit 2000ae5429.
This was intended as a fix for i686 cross compilation, but it has had
other unforeseen consequences, such as breaking rust-bindgen.
Always set `SRCTOP`, set it with abs path
llvmPackages: Bump minimum version for FreeBSD
llvmPackages_*, libgcc, compiler_rt: Hack in enough libs that one can compiler C
freebsd.compat: Rename some things to work around cc-wrapper change
0bea4a194f / #191724 in particular
Since the progress bar results in large output that is broken due to the use of
ncurses and we already use the flag that gives verbose output on test failures,
let's just disable the progress bar.
lit (LLVM Integrated Tester) [0] by default uses as many threads as the build host
has cores, ignoring the user's core settings for the build.
This passes the configured core count on to lit, along with LLVM's default
settings for it which we otherwise override in the process [1].
[0]: https://www.llvm.org/docs/CommandGuide/lit.html
[1]: 329fda39c5/llvm/CMakeLists.txt (L559-L565)
The missing xcrun meant builtins were missing from darwin. This
apparently wasn't an issue until now, but is in projects using
`@available` checks. (The ARM64 hack was apparently the previous
solution to fixing broken SDK detection.)
The new LLVM commit is just before the LLVM 15 fork off.
The readme describing upgrade process so it is easier for others to do.
Co-Authored-By: Dylan Green <Dylan.Green@Obsidian.Systems>
Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
