Accidental Public Exposure of C Global Symbols in Shared Libraries

Problem

When 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.

Goal

Determine a reliable strategy to prevent unintended symbol export while maintaining portability and future extensibility of the library.

Uncertainty

It 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.

Questions

1. Under which circumstances does a static global symbol get exported in a shared library on GCC, MSVC, and Clang?
2. How do visibility attributes interact with static when both are applied to the same symbol?
3. What platform‑specific linker options can reliably override compiler defaults to enforce internal linkage?