Bug 2047148
| Summary: | -D_FORTIFY_SOURCE not defined on x86_64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vitaly <vitaly> |
| Component: | annobin | Assignee: | Nick Clifton <nickc> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aoliva, dmalcolm, fweimer, jakub, jwakely, law, mpolacek, msebor, nickc, rjones, sipoyare |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-27 11:35:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2046784, 2047002 | ||
|
Description
Vitaly
2022-01-27 10:05:54 UTC
All x86_64 builds are affected. If `-Werror` is not set, it just a warning. Example from my nheko package: [27/267] /usr/bin/g++ -DQAPPLICATION_CLASS=QApplication -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/builddir/build/BUILD/nheko-0.9.1/redhat-linux-build/third_party/SingleApplication-3.3.2 -I/builddir/build/BUILD/nheko-0.9.1/third_party/SingleApplication-3.3.2 -I/builddir/build/BUILD/nheko-0.9.1/redhat-linux-build/third_party/SingleApplication-3.3.2/SingleApplication_autogen/include -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall -Wextra -pipe -pedantic -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code -Wno-attributes -DNDEBUG -fPIC -fPIC -std=gnu++17 -MD -MT third_party/SingleApplication-3.3.2/CMakeFiles/SingleApplication.dir/singleapplication_p.cpp.o -MF third_party/SingleApplication-3.3.2/CMakeFiles/SingleApplication.dir/singleapplication_p.cpp.o.d -o third_party/SingleApplication-3.3.2/CMakeFiles/SingleApplication.dir/singleapplication_p.cpp.o -c /builddir/build/BUILD/nheko-0.9.1/third_party/SingleApplication-3.3.2/singleapplication_p.cpp /builddir/build/BUILD/nheko-0.9.1/third_party/SingleApplication-3.3.2/singleapplication_p.cpp: warning: -D_FORTIFY_SOURCE not defined annobin: /builddir/build/BUILD/nheko-0.9.1/third_party/SingleApplication-3.3.2/singleapplication_p.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined That is already fixed in annobin-10.51-2.fc36 I think we need to debug why annobin got so much worse at becoming incompatible with any gcc *.opt changes whatsoever, that certainly wasn't the case before. > That is already fixed in annobin-10.51-2.fc36
Builds fine now, thanks.
(In reply to Jakub Jelinek from comment #3) > That is already fixed in annobin-10.51-2.fc36 > I think we need to debug why annobin got so much worse at becoming > incompatible with any gcc *.opt changes whatsoever, that certainly wasn't > the case before. I could really use some help tracking down why the plugin is so flaky. The problem with -D_FORTIFY_SOURCE and -D_GLIBCXX_ASSERTIONS might be explainable however. The annobin plugin scans the gcc command line by walking through the save_decoded_options[] array. If the field layout of this array changes between versions of gcc, then the walk will end up looking in the wrong places. Walking save_decoded_options is generally fine (with the exception when the structure changes, as happened e.g. in https://gcc.gnu.org/r12-6839 - sorry about that), but it depends on what fields from it you rely on. The OPT_* values do change quite often, so relying on opt_index in there would require translation through cl_options or something. orig_option_with_args_text or canonical_option might be more reliable. (In reply to Jakub Jelinek from comment #6) > orig_option_with_args_text or canonical_option might be more reliable. Thanks. The canonical_option array looks perfect for my needs. I will update the plugin to use it. One question though - can I rely upon canonical_options being present in older versions of GCC ? Annobin still builds for RHEL-6.... With the plugin switching in redhat-rpm-config, I don't think these ABI stability kludges will be needed anymore. We ensure matching ABIs by construction. canonical_options is GCC 4.6+. (In reply to Florian Weimer from comment #8) > With the plugin switching in redhat-rpm-config, I don't think these ABI > stability kludges will be needed anymore. We ensure matching ABIs by > construction. Yeah, but I need to find time to apply/tweak it on the gcc.spec side and test it. Will probably use mock for that because in koji gcc builds are super slow. |