Case 128: Symbol Binding Strengthened (Weak → Global)¶

Field	Value
Verdict	🟢 COMPATIBLE
Category	Quality (Compatible)
Platforms	Linux
Flags	—
Detected `ChangeKind`s	`symbol_binding_strengthened`
Source files	`examples/case128_symbol_binding_strengthened/`

Category: Symbol Binding | Verdict: 🟢 COMPATIBLE

What changes¶

The exported function helper is defined with weak binding (STB_WEAK) in v1 and strong/global binding (STB_GLOBAL) in v2. abicheck reports symbol_binding_strengthened and classifies the change as compatible. Detected at L0 — binding lives in the ELF symbol table.

Why it is compatible (and a good practice)¶

Strengthening a symbol's binding is backward compatible:

Every binary that previously resolved to the weak helper resolves to the same definition in v2 — the address and behavior are unchanged.
The only semantic difference is that a strong symbol can no longer be silently overridden by another strong definition elsewhere in the link. That removes a footgun (accidental interposition), it does not break callers.

This case is the benign counterpart to a binding weakening (global → weak), which is risky: a previously guaranteed definition could afterwards be overridden or left unresolved.

Code diff¶

v1	v2
`__attribute__((weak)) int helper(int x)`	`int helper(int x)`
`STB_WEAK`	`STB_GLOBAL`

How to reason about it¶

Weak → strong: safe (this case).
Strong → weak: review — a guaranteed symbol becomes overridable/optional.
Keep public API symbols strong; reserve weak binding for intentional fallback/override hooks and document them.

Source files¶

CMakeLists.txt
app.c
v1.c
v1.h
v2.c
v2.h