This does two changes:
* Add libomp -> llvm-libs dependency to satisfy rpmdeps.
* Add LLVM_USE_PERF to bundle_compat_lib to avoid an ABI change.
I've introduces a cmake_common_args variable so we have a place to
put cmake variables that should apply to both the main build and
the compat build.
+ /usr/lib/rpm/redhat/brp-fix-pyc-reproducibility /builddir/build/BUILDROOT/llvm19-19.1.3-4.fc40.x86_64/usr/lib/python3.12/site-packages
find: ‘/builddir/build/BUILDROOT/llvm19-19.1.3-4.fc40.x86_64/usr/lib/python3.12/site-packages’: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.VbdRja (%install)
* Install a redirection index.html page to point users to the
upstream HTML documentation.
* Remove myst parser patch for RHEL.
* Remove -DLLVM_INCLUDE_DOCS
* Add lldb man-pages
This change brings back some patches we had applied in LLVM 18.
And since the `bundle_compat_lib` switch in RHEL still builds LLVM 18,
I've added them here. This was easily possible due to #323.
This effectively allows us to build LLVM 19 in RHEL9 (see also RHEL-57461).
I've also added the `--gcc-install-dir` to the config file which is used
once clang is installed. This is to tell clang in RHEL which standard
library to link against.
We decided to no longer patch clang to default to DWARF4. Instead we tune
the default by adding `-gdwarf-4` to the config file.
RHEL-wise we've bumped the gts version from 13 to 14 (see RHEL-38228).
While we *are* building the gold plugin, I noticed that we're
no longer running the tests for it on f41 and rawhide. Add a
BuildRequires on binutils-gold to restore the tests.
We've established the habit of numbering patches the following way:
0-499: All patches that are unconditionally applied
500-1000: Patches applied under certain conditions (e.g. only on RHEL8)
1500-1599: Patches for LLVM 15
1600-1699: Patches for LLVM 16
1700-1799: Patches for LLVM 17
...
2000-2099: Patches for LLVM 20
The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow
us to "deprecate" a patch instead of deleting it right away.
Suppose llvm upstream in git is at version 20 and there's a patch living
in some PR that has not been merged yet. You can copy that patch and put it
in a line like:
Patch2011: upstream.patch
As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed.
There's no need for you to remove the "Patch2011:" line. In fact, we encourage you
to not remove it for some time. For compat libraries and compat packages we might
still need this patch and so we're applying it automatically for you in those
situations. Remember that a compat library is always at least one major version
behind the latest packaged LLVM version.
I've restored a patch for an older version of LLVM:
We needed to move the
`0001-Always-build-shared-libs-for-LLD.patch`
from the `0-499` range to the `19xx` (current release) and `20xx`
(snapshots) range. In addition the old version of the patch was restored
with the following command and added to the `18xx` range:
```
$ git show
0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch
> 0001-18-Always-build-shared-libs-for-LLD.patch
```
This was needed because the `bundle_compat_lib` (RHEL only) build
condition needs the old version of the patch.
Make the following changes:
* Fix a number of `%{?isa}` to use `%{?_isa}` instead.
* Add explicit lld-libs -> llvm-libs and lldb -> clang-libs
dependencies (to satisfy rpminspect rpmdeps analysis).
* Fix libomp-devel -> libomp dependency (it was accidentally
using libomp-devel -> llvm instead).
* Change all `= %{version}` requires to `= %{version}-%{release}`.
We were mostly already doing this, but missed some places.
The scriptlet tried to run llvm-config-%{maj_ver} when upgrading or
downgrading to check if ${maj_ver} has changed. Since postun runs
after the package files have been uninstalled this will always fail
to run the command. We should run instead llvm-config%{exec_suffix},
which in the case of upgrades or downgrades will still be present,
installed from the new package.
Backport patch from https://github.com/llvm/llvm-project/pull/111831
to fix openmp affinity tests on some brew ppc runners.
Also add one more openmp test to the ignore list for s390x.
Also add --time-tests to the lit args -- I had one instance where
openmp tests were running for 4h on s390x. If this happends again,
this should help determine which tests take so much time.
A large number of openmp tests using tsan fail when we hit certain
machines on the rhel8-beefy channel in brew, because they appear
to the use 5-level page tables. This results in memory being
mapped in places where tsan does not expect it.
See https://github.com/llvm/llvm-project/issues/111492 for more
context.
Work around this by disabling the openmp tests that use tsan if
the cpu has the la57 feature.
We currently disable rpath during both build and install. Instead,
we use LD_LIBRARY_PATH to allow the built clang to find the
libLLVM.so etc objects.
However, this does not work well if the system clang and the
clang being built have the same version. During the build, we
use both the system clang and the just-built clang, and they
need to use the system and just-built shared objects respectively.
However, use of LD_LIBRARY_PATH causes us to always use the
just-built objects as long as the versions match.
This is a problem in two scenarios: When building compat packages
for the current system LLVM version, we mix system clang with
compat libraries, which assume different paths. And when building
release candidates, a build using a previous rc of a newer rc
may use ABI-incompatible objects, because we don't version sonames
on rc versions.
Fix this by keeping the rpath during the build and only stripping
it on installation using the CMAKE_SKIP_INSTALL_RPATH option.
For manually installed binaries, we need to also manually strip
the rpath using chrpath.
This way system clang will use system libraries, and just-built
clang will use just-built libraries.
Before we had a very long list of CMake arguments.
There was no room for annotation through comments. Now we have a new
global called `%cmake_config_args` that one can append to.
I've created these `#regions` to group the options for each sub-project:
```
#region clang options
#region compiler-rt options
#region docs options
#region lldb options
#region llvm options
#region openmp options
#region test options
#region misc options
```
This spurious failure has been observed both on aarch64 in fedora
rawhide koji and on ppc64le in c10s koji.
I've filed an upstream issue to track this here:
https://github.com/llvm/llvm-project/issues/111140
Each `#region XY` now has an `#endregion XY` instead of just
`#endregion`. This is optional and `XY` does not have to be repeated for
the "system" to work but it makes working with regions a bit more
convenient.
```
#region globals...
#region packages...
#region prep...
#region build...
#region install...
#region check...
#region misc...
#region files...
#region changelog...
```
