RHEL & EPEL 8 builds fail due to differences in CMake or defined rpm macros

Ask Fedora
,
1

Introduction

For the past four years I have been the RPM package maintainer for SLiM, an evolutionary and population genetics simulation framework (slim) with its own Qt-based IDE (SLiMgui) and programming language for writing models (Eidos, with an interpreter eidos). The developer of SLiM—Ben Haller—is ready to tag and release SLiM 4.3 on GitHub, but we are having issues with building the SLiM RPM package for RHEL 8 and EPEL 8 on COPR at this time.

One year ago our RPM spec file had less macros in it, but we were able to build for the distributions in the following bulleted list. The spec file for v4.0.1, which is what we built on COPR a bit over one year ago, is available here on GitHub. The modern spec file is available on GitHub, using macros, is unable to build for EPEL 8 or RHEL 8; please note that other changes to the spec file reflect contributions back to the upstream to simplify the RPM build process and the spec file itself.

  • centos-stream-8-x86_64
  • centos-stream-9-x86_64
  • epel-8-x86_64
  • fedora-35-x86_64
  • fedora-36-x86_64
  • fedora-37-x86_64
  • fedora-38-x86_64
  • fedora-39-x86_64
  • fedora-rawhide-x86_64
  • opensuse-leap-15.3-x86_64
  • opensuse-tumbleweed-x86_64

Attempts at resolution of the issue

Assuming the problem is in RHEL itself

I have been in contact with @nickc in the Red Hat Jira regarding an open GitHub issue in the SLiM project. During my initial investigation, I was befuddled by the error and decided that the problem lay with the GNU linker ld provided by the RHEL 8 binutils package. That was the wrong conclusion, so @nickc is now closing the issue after being a helpful partner in discussion for close to one month.

Communications were relayed by me from Nick to Ben Haller, the developer of SLiM.

Concluding the problem lay with the interaction of CMake, rpmbuild, and the defined RPM macros in RHEL 8

Normally %_vpath_builddir expands to redhat_gnulinux_x86_64 or something like that, and that is the name of the directory in which an out-of-source build occurs. On RHEL 8, however, this macro is undefined and the

For the v4.0.1 build on RHEL 8 the following worked without issue.

%build
cmake -DBUILD_SLIMGUI=ON ./SLiM-%{version}/
make

Now, however, I need to specify the following in order to get a successful build on RHEL 8 with COPR.

%build
%if 0%{?rhel} == 8
%if "%_vpath_builddir" != "%_vpath_srcdir"
echo "current directory: %(pwd)"
echo "source directory: %_vpath_srcdir"
echo "build directory: %_vpath_builddir"
mkdir -p %_vpath_builddir
%else
%{warn "The build directory is the same as the source directory on RHEL 8!"}
%endif


## Tell CMake where the source directory and the build directory are, directly.
%cmake -S %_vpath_srcdir -B %_vpath_builddir -DBUILD_SLIMGUI=ON
cd %_vpath_builddir
%else
# rpmbuild is not running on RHEL 8
%cmake -DBUILD_SLIMGUI=ON
%endif


%cmake_build

The comments on the first and last line of that block don’t exist in the actual spec file, they’re insertions in this discussion only.

I’d like to understand what changed between 2022-09-14 and 2024-09-09 in RHEL 8, COPR, rpmbuild, rpm, etc. such that I needed to write this workaround.

During the course of my debugging I used SSH access to a builder, but there is little documentation surrounding this area of work and I’d like to work with some people who are more experienced to flesh out the documentation for this.

The documentation for some RPM macros themselves are poorly documented in the RPM Manual: macros section, e.g. %dump and %trace. Even %echo seemed to cause me issues, for instance, see the spec file in this commit.

COPR WARS: A New Hope

I finally have successfully done an out-of-tree build on RHEL 8 through COPR, which avoids a name collision issue that otherwise occurs. Unfortunately the %install stage now fails!

I’d really appreciate some help and education from my comrades in RPM packaging.

Addendum

  • It’s worked pleasantly for us to declare a conflict between our package SLiM on COPR and the slim package in the official Fedora repositories which provides the Simple Login Manager; we haven’t had any complaints from our user base, which is what we care about, and we aren’t aiming to have SLiM enter the official Fedora RPM repository at this time. There is a binary name conflict, which the upstream of SLiM is adamant about; we will not accommodate that login manager, so we’re content remaining out of the official Fedora repositories for the time being.
  • We’ve tried making a Flatpak before for SLiMgui, but we prefer to ship all three binaries (slim, SLiMgui and eidos in a single package and Flatpak simply isn’t the platform for that).