GCC LTO: Uncertain handling of -fcommon vs -fno-common during linking

Direct answer

-fcommon is not a documented weak-symbol mechanism in GCC, and LTO does not change that contract. It emits mergeable ELF common symbols for tentative C definitions; -fno-common emits ordinary strong definitions. When two translation units contain int g; and are compiled with -fno-common, the linker sees two strong definitions and reports duplicates. The behavior is governed by ELF symbol resolution and the flags used on every object, not by an LTO-specific weak promotion.

Confirmed facts

• GCC 10 changed the default for C from -fcommon to -fno-common. Later releases inherit that default unless overridden.
• Under -fcommon, uninitialized file-scope variables become STT_COMMON symbols that the linker can merge. Under -fno-common, they become allocated .bss definitions.
• LTO performs whole-program analysis at link time, but it does not relax the linker's duplicate-definition rules for strong symbols.

Likely explanation

The errors you see are most likely caused by one of two conditions: (1) every object was compiled with -fno-common, so multiple tentative definitions are now strong and collide; or (2) objects were compiled with different settings, so some carry common symbols and others carry strong definitions. A non-LTO link can succeed while the LTO link fails if the LTO link sees a different set of objects or flags, because LTO re-examines the full symbol table. Treat version-specific differences between GCC 11, 12, and 13 as unverified until reproduced with your exact toolchain.

Steps for this case

1. Make the setting uniform. Recompile every translation unit and the final link with the same -fcommon or -fno-common flag. Do not mix.
2. Confirm the driver default for your installed GCC:

   gcc -Q --help=common | grep -E -- '-f(no-)?common'

3. Inspect the object symbols before linking:

   readelf -sW a.o b.o

   Expect COM/STT_COMMON entries under -fcommon and .bss object definitions under -fno-common.
4. If the flags are uniform and duplicates remain, remove the tentative-definition pattern. Declare the variable extern in a header and define it in exactly one .c file. In C++, prefer a single definition or an inline variable.

One diagnostic that changes the recommendation

Capture the exact LTO link command and run readelf -s on one failing object. If any object used a different -fcommon setting, fix flag uniformity first. If all objects share the same setting and still fail, the source layout is the problem and you should move to the single-definition pattern.

What not to rely on

Do not treat common symbols as a portable substitute for weak symbols, version scripts, or visibility controls in shared libraries. Common-symbol merging is ELF-specific and does not provide the override semantics of a weak definition. For new code, the single-definition-plus-extern strategy is the portable choice regardless of LTO.