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...
```
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.
* %check: export LD_LIBRARY_PATH because runtimes use external cmake projects that wouldn't find libclang++.so
* %check: use LLVM's LIT_XFAIL to mark tests that are expected to fail and don't just delete them
* clang: bring over *.patch files
* clang: remove build requires tags from clang package that are already defined by main llvm package
* clang: remove duplicates found in llvm globals and use %{pkg_datadir} instead of %{install_datadir}
* clang: rename and use pkg_name -> pkg_name_clang
* clang: use %{pkg_name_clang} instead of %{name}
* compiler-rt and libomp: wrap in %if %{without compat_build}
* libomp: also build libomp for s390x (See https://github.com/llvm/llvm-project/pull/66081)
* libomp: exclude libomp-devel on s390x just like libomp itself
* libomp: introduce pkg_name_libomp and cleanup the globals
* libomp: remove gdb-plugin (NEED TO CONFIRM IF THIS IS REALLY TRUE)
* libomp: filter out flaky libomp test: ompt/teams/distribute_dispatch.c
* llvm: add BuildRequires: graphviz to llvm-doc
* llvm: use %{pkg_name_llvm} instead of %{name}
* make: added temporary Makefile so I can more easily run srpm or rpm builds locally
* make: Added local-tmt-vm target (not really useful yet)
* rpm: for non-RHEL add prefix like "Jan 05 16:17:06" to every log line This should help in finding out how long things take to build/install/...
* rpm: fully specify %files for top-level packages
* rpm: make all packages fully qualified
* rpm: obsolete llvm-snapshot-builder
* rpm: remove BuildRequires: python3-lit because we have it in-tree
* rpm: remove BuildRequires: tags for clang and llvm specifics as we're building in-tree
* rpm: rename %llvm_srcdir -> %srcdir_llvm
* rpm: rename %pkg_name -> %pkg_name_llvm
* rpm: use full qualified name in %description
* rpm: use region comments in spec file to group by package. This allows editors to fold text to get a better overview
* rpmlint: update rc file to reflect clang and compiler-rt (libomp has no rpmlint rc file)
* use python-lit from within tree
