Closed mrc0mmand closed 4 months ago
A possible reason for this is that CXXFLAGS
is reflected into the compilations of individual files but not in the link. You could achieve this by setting LDFLAGS
similarly.
The behavior matches my current understanding of the convention, but since -flto
is required at compilation and link time, it seems you're expecting CXXFLAGS
is also used for the link step.
I was confused why this doesn't seem to be an issue for other packages, and it looks like some/other build systems do what you describe automagically, i.e.:
$ meson init -l cpp
...
$ CXXFLAGS="-O2 -g -fstack-protector-strong -flto=auto" meson setup build
...
$ ninja -C build -v
ninja: Entering directory `build'
[1/2] c++ -Imeson.p -I. -I.. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 -O0 -g -O2 -g -fstack-protector-strong -flto=auto -MD -MQ meson.p/meson.cpp.o -MF meson.p/meson.cpp.o.d -o meson.p/meson.cpp.o -c ../meson.cpp
[2/2] c++ -o meson meson.p/meson.cpp.o -Wl,--as-needed -Wl,--no-undefined -O2 -g -fstack-protector-strong -flto=auto
$ objdump -Wi build/meson | grep DW_AT_producer
<d> DW_AT_producer : (indirect string, offset: 0): GNU GIMPLE 13.3.1 20240522 (Red Hat 13.3.1-1) -mtune=generic -march=x86-64 -g -g -O0 -O2 -O2 -fno-openmp -fno-openacc -fno-pie -fcf-protection=none -fstack-protector-strong -fltrans
<fe> DW_AT_producer : (indirect string, offset: 0x23a): GNU C++14 13.3.1 20240522 (Red Hat 13.3.1-1) -mtune=generic -march=x86-64 -g -g -O0 -O2 -std=c++14 -fstack-protector-strong -flto
$ grep . CMakeLists.txt foo.cxx
CMakeLists.txt:cmake_minimum_required (VERSION 3.7)
CMakeLists.txt:project (Foo)
CMakeLists.txt:add_executable(Foo foo.cxx)
foo.cxx:#include <iostream>
foo.cxx:int main (void) {
foo.cxx: std::cout << "Hello" << std::endl;
foo.cxx: return 0;
foo.cxx:}
$ mkdir build && cd build
$ CXXFLAGS="-O2 -g -fstack-protector-strong -flto=auto" cmake ..
...
$ make VERBOSE=1
/usr/bin/cmake -S/home/mrc0mmand/tmp/cmake -B/home/mrc0mmand/tmp/cmake/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/mrc0mmand/tmp/cmake/build/CMakeFiles /home/mrc0mmand/tmp/cmake/build//CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/mrc0mmand/tmp/cmake/build'
make -f CMakeFiles/Foo.dir/build.make CMakeFiles/Foo.dir/depend
make[2]: Entering directory '/home/mrc0mmand/tmp/cmake/build'
cd /home/mrc0mmand/tmp/cmake/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/mrc0mmand/tmp/cmake /home/mrc0mmand/tmp/cmake /home/mrc0mmand/tmp/cmake/build /home/mrc0mmand/tmp/cmake/build /home/mrc0mmand/tmp/cmake/build/CMakeFiles/Foo.dir/DependInfo.cmake "--color="
make[2]: Leaving directory '/home/mrc0mmand/tmp/cmake/build'
make -f CMakeFiles/Foo.dir/build.make CMakeFiles/Foo.dir/build
make[2]: Entering directory '/home/mrc0mmand/tmp/cmake/build'
[ 50%] Building CXX object CMakeFiles/Foo.dir/foo.cxx.o
/usr/bin/c++ -O2 -g -fstack-protector-strong -flto=auto -MD -MT CMakeFiles/Foo.dir/foo.cxx.o -MF CMakeFiles/Foo.dir/foo.cxx.o.d -o CMakeFiles/Foo.dir/foo.cxx.o -c /home/mrc0mmand/tmp/cmake/foo.cxx
[100%] Linking CXX executable Foo
/usr/bin/cmake -E cmake_link_script CMakeFiles/Foo.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -g -fstack-protector-strong -flto=auto CMakeFiles/Foo.dir/foo.cxx.o -o Foo
make[2]: Leaving directory '/home/mrc0mmand/tmp/cmake/build'
[100%] Built target Foo
make[1]: Leaving directory '/home/mrc0mmand/tmp/cmake/build'
/usr/bin/cmake -E cmake_progress_start /home/mrc0mmand/tmp/cmake/build/CMakeFiles 0
$ objdump -Wi Foo | grep DW_AT_producer
<d> DW_AT_producer : (indirect string, offset: 0): GNU GIMPLE 13.3.1 20240522 (Red Hat 13.3.1-1) -mtune=generic -march=x86-64 -g -g -O2 -O2 -fno-openmp -fno-openacc -fno-pie -fcf-protection=none -fstack-protector-strong -fltrans
<225> DW_AT_producer : (indirect string, offset: 0xf8f): GNU C++17 13.3.1 20240522 (Red Hat 13.3.1-1) -mtune=generic -march=x86-64 -g -O2 -fstack-protector-strong -flto
Can you try the patch in #4200?
This has been fixed now in both release-2
and master
branches, so will be picked up in the next release. Thanks for reporting this
Thank you! I'm preparing a botan3 package for Fedora, so the patch for the 3.x (master) branch is much appreciated.
@mrc0mmand That's great to hear. Don't know if you've seen them already but there are some notes for distributors that may be helpful.
While preparing another batch of botan2 updates in Fedora, I noticed a failing check in
annocheck
:Making
annocheck
a bit more verbose shows where this information comes from:With this information I was also able to reproduce this with a reduced set of build flags on the latest main (i.e. botan3):
Notice that
-fstack-protector-strong
is missing from allGNU GIMPLE
lines, causingannocheck
to fail. When building with the full set of Fedora build flags (rpm --eval "%{build_cxxflags}"
) I noticed that there are other flags missing as well (-fexception
,-ffat-lto-objects
, ...).I've never encountered this error from
annocheck
before, so I'm not really sure who to blame here.