Fedora Account System
Red Hat Associate
Red Hat Customer
Hello - We're facing an issue where non-RPM builds using sip fail because RPM-specific compiler and linker flags are embedded in sipconfig.py. This is probably not a problem for downstream RPM builds which use sip because the necessary environment variables are defined. Specifically, we see the following compilation failure message: ``` g++: fatal error: environment variable ‘RPM_ARCH’ not defined ``` This seems to be caused by the inclusion of one or more RPM-specific `-specs=...` flags in the captured compile flags in sipconfig.py. I don't have a full understanding of why these flags need to be captured and used when compiling downstream code using sip, but I don't think these flags should be present. We were able to work around the problem by specifically removing the `-specs=...` flags from the captured flags during sip's build. I've attached a patch which does this, which I hope can be used to arrive at an acceptable solution. Reproducible: Always
Created attachment 2051403 [details] Patch to drop -specs= from captured flags
Created attachment 2051405 [details] Patch to drop -specs= from captured flags
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
Still present in f43 and rawhide, resetting version to rawhide.
The compiler flag -specs=/usr/lib/rpm/redhat/redhat-package-notes is used when compiling and linking programs under Red Hat Enterprise Linux (RHEL) or Fedora to automatically embed RPM package metadata directly into the executable binaries and libraries. Why do Fedora do this? Embedding these package notes provides major benefits for system maintenance, debugging, and security: - Crash Analysis (Core Dumps): If a program crashes and generates a core dump, the operating system (or analysis tools like coredumpctl) can instantly read exactly which RPM package and version the crashing binary came from—even if the package has since been updated or uninstalled. - Security Audits: Vulnerability scanners can scan the entire filesystem for known vulnerable binaries by simply reading the ELF metadata, without having to rely on an intact or accessible RPM database. - Identifying "Orphaned" Files: It makes it instantly clear whether a binary on the system was installed via the package manager or compiled manually outside of it. Therefore We cannot drop the -spec option. If you want to build in your local development, please define for example export RPM_ARCH=$(uname -m) RPM_PACKAGE_NAME="test" RPM_PACKAGE_VERSION="1.0"
> Why do Fedora do this? > Embedding these package notes provides major benefits for system maintenance, debugging, and security I understand why these flags are here for RPM builds. All RPM builds, including projects downstream of this project, should continue to have those flags. It is _not_ appropriate for this package to give the flags to those packages implicitly. Their builds should get the flags from the RPM build process in the same way that this one does, per packaging policy. > Therefore We cannot drop the -spec option. If you want to build in your local development, please define for example export RPM_ARCH=$(uname -m) RPM_PACKAGE_NAME="test" RPM_PACKAGE_VERSION="1.0" This is not acceptable. It's a terrible look for Fedora. No other major Linux distribution that our project supports requires arbitrary environment variables set in order to generate metadata during builds for a packaging system that isn't even being used.