求助：编译添加-D_FORTIFY_SOURCE=2后目标二进制未实现Fortify加固的原因排查

Let’s dig into why your particular binary isn’t picking up FORTIFY_SOURCE protections even with global CMake flags set—this is a common gotcha, but there are clear steps to diagnose and fix it.

Common Causes & Fixes #

1. Target-Specific Flags Overriding Global Settings #

It’s possible your problematic target has its own compile options that are overriding the global -D_FORTIFY_SOURCE=2 or -O2 flags. CMake lets targets define their own flags via target_compile_options, set_target_properties, or even overriding CMAKE_CXX_FLAGS for that target alone.

How to check:

• Run your build with verbose output: make VERBOSE=1 or ninja -v
• Locate the compile command for your target’s source files. Look for the presence of both -O2 and -D_FORTIFY_SOURCE=2—if either is missing, that’s the issue.
• Check your CMakeLists.txt for any target-specific flags that might be clearing or overwriting these settings (e.g., target_compile_options(your_target PRIVATE -O0) would disable optimization entirely).

2. Optimization Level Too Low #

FORTIFY_SOURCE requires at least -O1 optimization to work—without it, GCC won’t replace unsafe standard library calls with their fortified counterparts. Even if you set -O2 globally, a target might have its optimization level forced down.

How to check:

• Look for lines like set_target_properties(your_target PROPERTIES COMPILE_FLAGS "-O0") in your CMake config.
• Verify the CMAKE_BUILD_TYPE isn’t being overridden for this target (e.g., accidentally setting it to Debug which defaults to -O0).

3. Conflicting Compiler Flags #

Certain flags disable the built-in functions that FORTIFY_SOURCE relies on. The most common culprits are:

• -fno-builtin: Disables all GCC built-in functions, including the fortified variants
• -ffreestanding: Treats the code as freestanding (no standard library), which skips FORTIFY checks
• -nostdlib/-nodefaultlibs: Excludes the standard library entirely

How to check:

• Scan the target’s compile command for these flags. If present, remove them (or adjust if they’re absolutely necessary) and rebuild.

4. Target Type or Linking Quirks #

While less likely (since other binaries work), double-check if your target is configured differently:

• Is it an OBJECT library instead of an executable? Object libraries aren’t linked into a final binary, so FORTIFY checks happen at link time for executables.
• Are you using a custom linker script or non-standard linking flags that might strip fortified symbols?

5. GCC Version/Compiler Mismatch #

Even though you’re using GCC 9.3.0 globally, ensure this target isn’t accidentally using a different compiler (e.g., clang, or an older GCC version installed elsewhere).

How to check:

• Look at the compile command’s compiler path (e.g., /usr/bin/g++ vs. a custom install). Run <compiler-path> --version to confirm it’s GCC 9.3.0.

Quick Test to Isolate the Issue #

Take one of the source files from your problematic target and compile it manually with the required flags:

g++ -O2 -D_FORTIFY_SOURCE=2 -std=c++17 -c your_source.cpp -o test.o

Then inspect the object file to see if fortified functions are present:

objdump -d test.o | grep -E "__memcpy_chk|__strcpy_chk|__printf_chk"

If you see these _chk variants, the issue is definitely in your CMake configuration for the target. If not, there might be something in the source code itself bypassing FORTIFY (though checksec showing Fortifiable = 4 makes this unlikely).

内容的提问来源于stack exchange，提问作者Arturo Gonzalez