-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPM building challenges #14
Comments
Hey, thank you for all your contributions! In general I find the approach of using build containers very clean. Since you now provided a spec file(#18), we might be able to use a centos container and build the rpm properly. |
Hi Carsten! I still think building a RPM within a CentOS container won't solve the compatibility issue. If the container uses say CentOS 7.x to build the RPM, that package will depend on infiniband-diags 2.1.0. But if it's built (via Docker) on a CentOS 8.x system (that provides infiniband-diags 2.2.0), the resulting RPM won't install on the host, and even if it did, it wouldn't work. This is why RPMs (and packages in general) have to be built specifically for the distribution they're intended to be used on. And unfortunately, building them in a container doesn't work well for that use case. |
Hi Both, we also have been hit by issues with the RPMs built in the containers not working on our RHEL7 hosts and I initially came here to open a ticket about that. Thankfully with the spec file in #18, I have been able to build a RPM for 2.08 that at least in initial testing seems to work just fine on our RHEL7.8 hosts. Frederik |
Hi!
It's very cool that you're providing RPMs and a way to build them for this project, thanks!
But unfortunately, there are a number of issues with the build-in-Docker approach, IMHO.
The RPMs are built with libraries that are provided by the distribution used in the container (Debian), which will likely be quite different from those used on the machine where the RPM will be installed (likely running RHEL or CentOS). That will result in a non-working package, which is why it would be much better to allow building the RPM natively on the host, rather than in a container. So in that sense, providing a SPEC file could actually more effective than running fpm in a container.
An other issue is the C++17 build requirement: the RHEL/CentOS 7 installation base in pretty large and common in HPC circles, and the default compiler on those distributions only supports C++11 (and as an experimental feature, even).
Another point to note maybe is that RHEL8 doesn't support static linking anymore, so compiling infiniband-radar-daemon on RHEL8 will fail too, due to the
-static-libgcc -static-libstdc++
flags inCMakeLists.txt
:infiniband-radar-daemon/CMakeLists.txt
Line 3 in 2dddf34
I can work on some of those issues, if that helps, but I thought I'd share them here first.
The text was updated successfully, but these errors were encountered: