Am 19.03.24 um 08:11 schrieb Shung-Hsi Yu:
Right now I'm using the suggestion in SR#1134405, aligning to PostgreSQL's approach (product_libs_llvm_ver is defined in project config to the latest major LLVM version):
%if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{nil} %endif ... BuildRequires: llvm%{llvm_major_version}-devel The advantage of this approach is that you get the newest version that is (a) contained in the distribution and (b) supported by the package. On Tumbleweed, the package is typically the limiting factor, but on Leap you might actually support a newer LLVM than what is available. This will just select the highest version available then. But I ran into unresolvable build for bpftrace[1] on OBS with the error message:
conflict for providers of llvm-devel needed by bcc-devel, (provider llvm-devel obsoletes llvm17-devel)
I'm guessing this comes from the following dependency tree:
bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) | +------> bcc-devel -----> llvm-devel[2] (back when product_libs_llvm_ver was 17?)
You should probably only use llvm-devel for BuildRequires, and then add Requires corresponding to the version it was built with. The best way to do it would probably be BuildRequires: llvm%{llvm_major_version}-devel Requires: llvm%{_llvm_sonum}-devel This uses the macro defined in %{_rpmconfigdir}/macros.d/macros.llvm, which is part of llvmX-devel. By writing it like that, the package gets a requirement to the LLVM version it was built with, ensuring ABI compatibility. Best regards, Aaron