This should make it easier to analyze which parts of the build
are slow. The new package is only available in snapshot builds,
we don't want to ship it in production.
This ports the change from https://src.fedoraproject.org/rpms/compiler-rt/pull-request/67
to big-merge, which is a bit more complicated here due to the
explicit file lists.
By default compiler_rt_triple is the same as llvm_triple. For x86
it is i386-redhat-linux-gnu instead, with a symlink to the
llvm_triple i686-redhat-linux-gnu.
And then the file list also needs to ship that symlink.
The clang resource directory is always in lib/, while this was
creating the directories in lib64 (for 64-bit symbols).
This should fix the following error on ppc64le:
> error: Directory not found: /builddir/build/BUILDROOT/llvm-19.0.0~pre20240528.g1de1ee9cbabd64-1.fc39.ppc64le/usr/lib/clang/19/bin
Have a --with lto_build option, where LTO is enabled by default
for everything except i686 and riscv. Use that flag to condition
whether `-DLLVM_UNITTEST_LINK_FLAGS` is passed.
Additionally, make use of the new Fat LTO functionality in rawhide
to use `-fno-lto` instead of `-Wl,-plugin-opt=O0` to save more
time linking unit tests.
We were defining lto_cflags in three places. It looks like on
aarch64 nil won (LTO disabled), while on other architectures
`-flto=thin` won.
I think on rawhide, this means that we're currently shipping
bitcode in static archives, because the required
`-ffat-lto-objects` option from redhat-rpm-config is missing.
Resolve this by leaving the option at its default value --
if enabling it on aarch64 causes issues, we can disable it just
there again.
Also reenable the LLVM_UNITTEST_LINK_FLAGS option, which should
reduce the amount of time LTO takes.
Fix these errors on s390x by excluding the files on that arch:
File not found: /builddir/build/BUILDROOT/llvm-19.0.0~pre20240526.gc87a7b3bdb6737-1.fc41.s390x/usr/lib/clang/19/lib/s390x-redhat-linux-gnu/clang_rt.crtbegin.o
File not found: /builddir/build/BUILDROOT/llvm-19.0.0~pre20240526.gc87a7b3bdb6737-1.fc41.s390x/usr/lib/clang/19/lib/s390x-redhat-linux-gnu/clang_rt.crtend.o
File not found: /builddir/build/BUILDROOT/llvm-19.0.0~pre20240526.gc87a7b3bdb6737-1.fc41.s390x/usr/lib/clang/19/lib/s390x-redhat-linux-gnu/liborc_rt.a
Fix this error on i686 by explicitly creating the directory.
This matches what the implementation did pre-big-merge. I think
we do want to keep this directory structure consistent across all
arches.
Directory not found: /builddir/build/BUILDROOT/llvm-19.0.0~pre20240526.gc87a7b3bdb6737-1.fc41.i386/usr/lib/clang/19/bin
This should fix this error which appears on RHEL only:
```
Configuration error:
There is a programmable error in your configuration file:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/sphinx/config.py", line 326, in eval_config_file
execfile_(filename, namespace)
File "/usr/lib/python3.9/site-packages/sphinx/util/pycompat.py", line 88, in execfile_
exec(code, _globals)
File "/builddir/build/BUILD/llvm-project-c1d5cc99c6ba8e897ea145dbb2221a155b5e3e5a/llvm/redhat-linux-build/tools/clang/docs/conf.py", line 42, in <module>
import myst_parser
ModuleNotFoundError: No module named 'myst_parser'
```
See also https://github.com/fedora-llvm-team/llvm-snapshots/issues/492
The list of supported sanitizers differs per target, and depending
on that some of these files may or may not be present. Use a
wildcard rather than explicitly listing this out.
Ensure the versioned llvm-config alternative gets removed during major
upgrades of the non-compat package.
Also add code that removes the versioned llvm-config alternatives of
the previous 3 LLVM versions. These versions didn't remove their own
versioned llvm-config alternative, leading to broken output, e.g.
llvm-config-16 points to llvm-config-64 from LLVM 17.
https://github.com/llvm/llvm-project/pull/92456 added a new
libclang_rt.ctx_profile.a library.
Given that these all have a fixed prefix, I think it's fine to
use a wildcard for them instead of explicitly listing them.
Before I've used `%ifnarch` in the `<FILE>` included with `%files -f <FILE>`.
This produced this error:
```
RPM build errors:
File must begin with "/": %ifnarch
File must begin with "/": i386
File must begin with "/": i486
File must begin with "/": i586
File must begin with "/": i686
File must begin with "/": pentium3
File must begin with "/": pentium4
File must begin with "/": athlon
File must begin with "/": geode
File must begin with "/": %endif
```
We can optimize this at any point in time later.
We had too many `*.so` libraries added to the `clang-devel` package.
Before we've added these implicitly by accident:
```
/usr/lib64/libLLVM.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libLTO.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libRemarks.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libclang-cpp.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libclang.so.19.0.0pre20240509.g943617d12ccbd3
/usr/lib64/libclang.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldCOFF.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldCommon.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldELF.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldMachO.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldMinGW.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/liblldWasm.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libomptarget.rtl.amdgpu.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libomptarget.rtl.cuda.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libomptarget.rtl.host.so.19.0pre20240509.g943617d12ccbd3
/usr/lib64/libomptarget.so.19.0pre20240509.g943617d12ccbd3
```
And now we're adding just these because these are the ones that used to
exist within the clang-devel package when it was still being built in
standalone mode:
```
/usr/lib64/libclang-cpp.so
/usr/lib64/libclang.so
```
