Accidental Public Exposure of C Global Symbols in Shared Libraries

Question

ProblemWhen building a shared library, global symbols that are not intended for external use can be inadvertently exported, leading to namespace pollution or security concerns. The C language provides the static keyword for internal linkage, but the default visibility rules differ across compilers and platforms. Additionally, visibility attributes and linker options can override static, creating ambiguity about which mechanism truly guarantees internal linkage.GoalDetermine a reliable strategy to prevent unintended symbol export while maintaining portability and future extensibility of the library.UncertaintyIt is unclear whether relying solely on static suffices, or if explicit visibility attributes or linker flags are required on each target platform. The interaction between static and visibility attributes can be confusing, and compiler defaults vary between Windows, macOS, and Linux.QuestionsUnder which circumstances does a static global symbol get exported in a shared library on GCC, MSVC, and Clang?How do visibility attributes interact with static when both are applied to the same symbol?What platform‑specific linker options can reliably override compiler defaults to enforce internal linkage?

Muntasir · Answer

Answer
Static alone does not guarantee that a symbol stays hidden in a shared library; the outcome depends on compiler defaults, explicit visibility attributes, and platform‑specific linker behavior.
Confirmed facts

GCC/Clang: By default symbols have default visibility. A static object gets internal linkage, but without -fvisibility=hidden or __attribute__((visibility("hidden"))) it can still appear in the dynamic symbol table (nm -D shows it). Adding the visibility attribute or compiling with -fvisibility=hidden guarantees the symbol is not exported, even when both static and the attribute are present.
MSVC: A static global has internal linkage, yet it will be exported if the build includes an explicit __declspec(dllexport) declaration or lists the symbol in a module‑definition (.def) file. In the absence of such directives, the symbol remains hidden.
Interaction: static controls linkage; visibility attributes control the symbol’s default visibility. When both are applied, the visibility attribute wins – a visibility("hidden") attribute forces the symbol to stay hidden regardless of static.

Steps to enforce internal linkage (portable)

Declare internal objects with static.
Add __attribute__((visibility("hidden"))) (GCC/Clang) or __declspec(dllexport) only for the API you intend to expose.
Compile with -fvisibility=hidden (GCC/Clang) to make hidden the default, then selectively mark exported symbols with __attribute__((visibility("default"))) or __declspec(dllexport).
On MSVC, avoid __declspec(dllexport) and .def entries for internal symbols; optionally use a .def file that lists only the public exports.
Verify: run nm -D lib.so (Linux/macOS) or dumpbin /EXPORTS lib.dll (Windows) and confirm the symbol does not appear.

Missing diagnostic detail
If you are using any explicit __declspec(dllexport) or a module‑definition file, please confirm whether the symbol in question is listed there; that determines whether additional hiding steps are required.

Accidental Public Exposure of C Global Symbols in Shared Libraries

Problem

Goal

Uncertainty

Questions

1 answer

Answer

Confirmed facts

Steps to enforce internal linkage (portable)

Missing diagnostic detail

Your perspective belongs here.

0 question comments