In rawhide we see this during the glibc build: configure:3966: gcc -O2 -g -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Werror -fstack-protector -xc /dev/null -S -o /dev/null configure:3969: $? = 0 But in ELN, we get this instead: configure:3966: gcc -O2 -g -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -specs =/usr/lib/rpm/redhat/redhat-annobin-cc1 -Werror -fstack-protector -xc /dev/null -S -o /dev/null /dev/null: error: -D_FORTIFY_SOURCE not defined [-Werror] Package versions: annobin-plugin-gcc-10.81-1.fc38.x86_64 gcc-12.2.1-1.fc38.x86_64 annobin-plugin-gcc-10.81-1.eln121.x86_64 gcc-12.2.1-1.eln121.x86_64 In both cases, the “annobin” plugin name is selected. So this really looks like a difference in the plugin itself.
This appears to be another gcc <-> annobin synchronization issue. The warning is only supposed to be generated when compiling with -flto enabled, but the ELN version is not honoring this requirement. Checking the root.log for the annobin-10.81-1.eln121 build shows the problem: DEBUG util.py:445: gcc x86_64 12.1.1-3.fc37.1 build 33 M So the plugin was built by gcc 12.1.1 but run on gcc 12.2.1. I will bump the annobin NVR in rawhide and create a new build. I assume that this will also then trigger a rebuild for ELN, although I am not 100% sure that this process is automatic.
(In reply to Nick Clifton from comment #1) > This appears to be another gcc <-> annobin synchronization issue. > > The warning is only supposed to be generated when compiling with -flto > enabled, but the ELN version is not honoring this requirement. Checking the > root.log for the annobin-10.81-1.eln121 build shows the problem: > > DEBUG util.py:445: gcc x86_64 12.1.1-3.fc37.1 build 33 M > > So the plugin was built by gcc 12.1.1 but run on gcc 12.2.1. > > I will bump the annobin NVR in rawhide and create a new build. I assume > that this will also then trigger a rebuild for ELN, although I am not 100% > sure that this process is automatic. This is very concerning. Why doesn't the redhat-rpm-config trigger run as expected? I'm trying to gather some logs, but it's kind of difficult. I'm not sure if that's even possible.
I think the issue is with the separate subpackage for the plugin. The installation order is: Installing : make-1:4.3-11.eln120.x86_64 8/11 Installing : gcc-12.2.1-1.eln121.x86_64 9/11 Running scriptlet: gcc-12.2.1-1.eln121.x86_64 9/11 Installing : annobin-plugin-gcc-10.81-1.eln121.x86_64 10/11 Running scriptlet: annobin-plugin-gcc-10.81-1.eln121.x86_64 10/11 Installing : gcc-plugin-annobin-12.2.1-1.eln121.x86_64 11/11 Running scriptlet: gcc-plugin-annobin-12.2.1-1.eln121.x86_64 11/11 Verifying : make-1:4.3-11.eln120.x86_64 1/11 Verifying : annobin-docs-10.81-1.eln121.noarch 2/11 Verifying : annobin-plugin-gcc-10.81-1.eln121.x86_64 3/11 The trigger only acts on gcc, though, and the plugin is not installed at this point. We either need to look at the version files only (disregarding the existenced of the .so files), or move the gcc version file into the same package as the .so file, and trigger on that package name (gcc-plugin-annobin, not gcc).
(In reply to Florian Weimer from comment #3) Hi Florian, > I think the issue is with the separate subpackage for the plugin. The > installation order is: > Installing : gcc-12.2.1-1.eln121.x86_64 > Installing : annobin-plugin-gcc-10.81-1.eln121.x86_64 > Installing : gcc-plugin-annobin-12.2.1-1.eln121.x86_64 > The trigger only acts on gcc, though, and the plugin is not installed at > this point. Hmm, yes, you are correct. > We either need to look at the version files only (disregarding the > existence of the .so files), or move the gcc version file into the same > package as the .so file, and trigger on that package name > (gcc-plugin-annobin, not gcc). Or we could trigger on gcc and gcc-plugin-annobin (and annobin-plugin-gcc). The plugin selection script copes well if it cannot find the version file and this way we would not have to modify the gcc package's packaging.
(In reply to Nick Clifton from comment #4) > (In reply to Florian Weimer from comment #3) > Hi Florian, > > > I think the issue is with the separate subpackage for the plugin. The > > installation order is: > > > Installing : gcc-12.2.1-1.eln121.x86_64 > > Installing : annobin-plugin-gcc-10.81-1.eln121.x86_64 > > Installing : gcc-plugin-annobin-12.2.1-1.eln121.x86_64 > > > The trigger only acts on gcc, though, and the plugin is not installed at > > this point. > > Hmm, yes, you are correct. > > > We either need to look at the version files only (disregarding the > > existence of the .so files), or move the gcc version file into the same > > package as the .so file, and trigger on that package name > > (gcc-plugin-annobin, not gcc). > > Or we could trigger on gcc and gcc-plugin-annobin (and annobin-plugin-gcc). > The plugin selection script copes well if it cannot find the version file > and this way we would not have to modify the gcc package's packaging. I'm not sure if adding to the set of triggering packages is the proper fix, or just a horrible kludge. Marek, Jakub, any preferences?
(In reply to Florian Weimer from comment #5) Hi Guys, So, just to be clear, there are 3 proposals to fix this problem: >>> We either need to look at the version files only (disregarding the >>> existence of the .so files), 1. Modify the redhat-annobin-plugin-select.sh script in the redhat-rpm-config package so that it assumes that if the gcc rpm has been installed, then the gcc-plugin-annobin rpm has-been or is-about-to-be installed. So that if the scripts detects that annobin was built using an earlier version of gcc it will choose the gcc built version of the plugin, *even if* it has not been installed yet. >>> or move the gcc version file into the same >>> package as the .so file, and trigger on that package name 2. Modify the gcc.spec file so the gcc-plugin-annobin subpackage contains a copy of the information provided by "gcc --print-file-name=rpmver". Then modify the redhat-annobin-plugin-select.sh script to trigger on the installation of gcc-plugin-annobin (rather than on just "gcc" as it does at the moment). >> Or we could trigger on gcc and gcc-plugin-annobin (and annobin-plugin-gcc). 3. Modify the redhat-annobin-plugin-select.sh script in redhat-rpm-config so that it triggers on the installation of annobin-plugin-gcc, gcc and gcc-plugin-annobin. Personally I like option 3 because it involves the least amount of work. All three options require changes to the redhat-rpm-config package, and whilst option 2 is technically the cleanest solution, it does also mean changing the gcc package.
Just a kind reminder that we need to fix this on all active branches (including downstream).
I suppose we can go ahead with 3) and see if it's sufficient.
FEDORA-2023-f1770ddcaf has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1770ddcaf
FEDORA-2023-f1770ddcaf has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days