Description of problem: I'm not sure if annobin is the right component for this, but what happens is a result of -flto[1] in combination with -Wp,-D_FORTIFY_SOURCE=2 preprocessor defines[2] when using annobin plugin to compile a preprocessed file. In particular, when a preprocessed file is compiled with -flto and -Wp,-D_FORTIFY_SOURCE=2, annobin reports: $ cat /tmp/test.i # 1 "<command-line>" #define _FORTIFY_SOURCE 2 #define _GLIBCXX_ASSERTIONS 1 int main() { return 0; } $ gcc -flto -fplugin=annobin -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -o /tmp/test.o -c /tmp/test.i annobin: <command-line>: Warning: -D_FORTIFY_SOURCE not defined annobin: <command-line>: Warning: -D_GLIBCXX_ASSERTIONS not defined I can see how the -Wp, arguments would be ignored for preprocessed input, but perhaps annobin should check if the preprocessed file has #define's? I guess I don't really know how exactly _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS work, nor why the macros in redhat-rpm-config define them using -Wp, rather than just -D. Version-Release number of selected component (if applicable): annobin-9.27-1.fc33.x86_64 redhat-rpm-config-166-1.fc33.noarch How reproducible: Always. Steps to Reproduce: 1. Create preprocessed C/C++ file 2. Compile preprocessed file with arguments: -flto -fplugin=annobin -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS Actual results: annobin: <command-line>: Warning: -D_FORTIFY_SOURCE not defined annobin: <command-line>: Warning: -D_GLIBCXX_ASSERTIONS not defined Expected results: _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS are defined accordingly for annobin. Additional info: Using -D rather than -Wp,-D for the defines fixes this, and annobin correctly defines _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS: $ gcc -flto -fplugin=annobin -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -o /tmp/test.o -c /tmp/test.i Similarly, compiling the non-preprocessed input directly works: $ gcc -flto -fplugin=annobin -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -o /tmp/test.o -c /tmp/test.c On the other hand, removing -flto, annobin does not warn that _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS are undefined: $ gcc -fplugin=annobin -fplugin-arg-annobin-verbose -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -o /tmp/test.o -c /tmp/test.i [1] https://fedoraproject.org/wiki/LTOByDefault [2] https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/4637e1bd5512b869bd07c58b7545d2528a9bc4c8/f/macros#_337
Hi Matthew, > I'm not sure if annobin is the right component for this, It is. > I can see how the -Wp, arguments would be ignored for preprocessed input, > but perhaps annobin should check if the preprocessed file has #define's? Unfortunately it can't. Annobin is a gcc plugin, and as such it does not get to see the text of the input. It only sees the input after it has been translated into one of gcc's internal formats. It can examine the command line used to invoke the compiler, but this too has been sanitized to remove any options that gcc thinks it will not need. (So -Wp, options are removed for preprocessed input). > I guess I don't really know how exactly _FORTIFY_SOURCE and > _GLIBCXX_ASSERTIONS work, nor why the macros in redhat-rpm-config define > them using -Wp, rather than just -D. I am not sure about that either. Perhaps because it looks more sophisticated ? :-) Detecting these preprocessor options is actually very hard. Since pre-processed files can be provided as input to the compiler, checking the command line is not necessarily reliable. (As you have seen). Examining the text of the input file is out, since it is not available to plugins. Checking for the effect of the pre-processor options is not really possible either because the compiler can optimize away or change there effects in ways that the plugin cannot reliably detect. So if you do need to use preprocessed files as inputs, I would suggest adding extra -D_FORTIFY_SOURCE=2 and -D_GLIBCXX_ASSERTIONS to the command line, even if they are already added by the rpm macros, and even if they are ignored by the compiler. > On the other hand, removing -flto, annobin does not warn that _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS are undefined: The reason for not warning in the general case is because of the preprocessed file input problem discussed above. The reason for warning with -flto is that LTO ignores preprocessor options, so if you are creating a set of object files to be passed to an LTO compilation at a later date, and you do not bother with the preprocessor options (assuming that they can be specified and processed when the LTO compilation happens), then you will be disappointed. Is this a serious problem for your builds ? One thing I could do is to add an option to the annobin plugin to tell it that these options have been defined and that it does not need to examine the command line at all. Eg: -fplugin-arg-annobin-define-_FORTIFY_SOURCE=2 A bit wordy, but it would work. But if this is not a big problem for you then I would prefer not to do this as more code = more opportunities for bugs. Cheers Nick
(In reply to Nick Clifton from comment #1) > > I guess I don't really know how exactly _FORTIFY_SOURCE and > > _GLIBCXX_ASSERTIONS work, nor why the macros in redhat-rpm-config define > > them using -Wp, rather than just -D. > > I am not sure about that either. Perhaps because it looks more > sophisticated ? :-) I think -Wp,-D... is needed because libtool breaks -D...
Anyway, whether _FORTIFY_SOURCE or _GLIBCXX_ASSERTIONS macros are defined when compiling an already preprocessed source is completely irrelevant, the presence or absence of those macros will not change anything. What matters is if those macros were defined during preprocessing of the source.
Hello Nick and Jakub, Thanks for the responses. For some additional background, this[1] is the issue I'm trying to fix: 1. Using the build2 build system, it compiles the preprocessed files. 2. Using redhat-rpm-config with -Wp,-D (rather than -D) in combination with -flto and annobin results in many warnings during compilation 3. These warnings result in the test suite failing because it doesn't expect to see warnings (which seems reasonable). > It is. I was thinking it might be redhat-rpm-config since things work with -D. > I am not sure about that either. Perhaps because it looks more sophisticated ? :-) The best I can figure the origins are this 15 year-old commit[2] which claims -D breaks Java. I don't know if this is still true. > I think -Wp,-D... is needed because libtool breaks -D... Perhaps this might be the case, though. > So if you do need to use preprocessed files as inputs, I would suggest adding extra -D_FORTIFY_SOURCE=2 and -D_GLIBCXX_ASSERTIONS to the command line, even if they are already added by the rpm macros, and even if they are ignored by the compiler. Indeed, this might be the easy solution for build2 to just translate -Wp,-D to -D. If libtool is the reason for this, it would not be relevant for build2. > Is this a serious problem for your builds ? It's a problem for build2 builds (or any buildsystem that compiles preprocessed input) which uses redhat-rpm-config macros, since we will now get annobin warnings on every compile. > One thing I could do is to add an option to the annobin plugin to tell it that these options have been defined and that it does not need to examine the command line at all. Eg: This may not be necessary since I'd either have to modify -Wp,-D to -D or add the annobin plugin arg when -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS is found in %build_c{,xx}flags for building build2. > But if this is not a big problem for you then I would prefer not to do this as more code = more opportunities for bugs. Yeah, it would be nice to find a simple solution with minimal effort for everyone involved. I guess I was hoping that might be just changing redhat-rpm-config macros from -Wp,-D to -D, but if it does break libtool, that's probably not an option. > Anyway, whether _FORTIFY_SOURCE or _GLIBCXX_ASSERTIONS macros are defined when compiling an already preprocessed source is completely irrelevant, the presence or absence of those macros will not change anything. Does this mean that annobin should not emit these warnings when compiling preprocessed source? Could it detect that preprocessed input was specified on the command line? This would probably fix my issue as well. Although, I'm not sure if annobin would be able to annotate the resulting binary correctly in this case. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1863299 [2] https://src.fedoraproject.org/rpms/redhat-rpm-config/c/1518ff2d14377c05ecf7cf9428e42964516883b4?branch=master
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Hi Matthew, Right - I have added a small patch to the annobin plugin which will stop it from complaining about missing pre-processor directives when it is examining an already pre-processed input file. Please try out annobin-9.28-1.fc33 and let me know if the problem still exists. Cheers Nick
Hey Nick, Thanks for the updated annobin. annobin-9.28-1.fc33 fixed my issue: no compiler annobin warnings are generated, and the object files are properly annotated for preprocessed input files. Best, Matthew
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
It looks like I am hitting very similar issue now in Fedora 36 mass rebuild (bug #2046792). All the build files emit the following errors: /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -Wall -Wextra -Wno-unused-parameter -Werror -Wstrict-aliasing=2 -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 -Wstrict-aliasing=2 -Wno-deprecated-declarations -c -o compat_strnlen.lo compat_strnlen.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -Wall -Wextra -Wno-unused-parameter -Werror -Wstrict-aliasing=2 -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 -Wstrict-aliasing=2 -Wno-deprecated-declarations -c compat_strnlen.c -fPIC -DPIC -o .libs/compat_strnlen.o make[3]: Leaving directory '/builddir/build/BUILD/opensc-0.22.0/src/common' compat_strnlen.c: error: -D_FORTIFY_SOURCE not defined [-Werror] The buildroot is using the following version of annobin: DEBUG util.py:446: annobin-plugin-gcc x86_64 10.48-4.fc36 build 813 k Is there something wrong on the annobin side, or in our spec file, that could cause this? https://src.fedoraproject.org/rpms/opensc/blob/rawhide/f/opensc.spec
I'm seeing the same thing with octomap (bug #2046781) - the warnings conflicted with -Werror and caused a build to fail: cd /builddir/build/BUILD/octomap-1.9.7/redhat-linux-build/octomap/src/math && /usr/bin/g++ -Doctomath_EXPORTS -I/builddir/build/BUILD/octomap-1.9.7/octomap/include -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 -Werror -Wextra -Wpedantic -fPIC -fPIC -std=gnu++11 -MD -MT octomap/src/math/CMakeFiles/octomath.dir/Pose6D.cpp.o -MF CMakeFiles/octomath.dir/Pose6D.cpp.o.d -o CMakeFiles/octomath.dir/Pose6D.cpp.o -c /builddir/build/BUILD/octomap-1.9.7/octomap/src/math/Pose6D.cpp /builddir/build/BUILD/octomap-1.9.7/octomap/src/math/Pose6D.cpp: error: -D_FORTIFY_SOURCE not defined [-Werror] annobin: /builddir/build/BUILD/octomap-1.9.7/octomap/src/math/Pose6D.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined
FEDORA-2022-72a33d9131 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-72a33d9131
FEDORA-2022-72a33d9131 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Rich Mattes from comment #11) > I'm seeing the same thing with octomap (bug #2046781) - the warnings > conflicted with -Werror and caused a build to fail: Which versions of gcc and annobin were being used when this happened ? Do you know if the problem is repeatable ? It is possible that this problem has been fixed by a rebuild of the annobin package...