I suppose because they are an ELF feature rather than a language feature?

Anyway you can (and should!) use -fvisibility=hidden and add __attribute__((__visibility__("default"))) to public symbols when writing a C library. It will make calls between non-visible symbols faster because the compiler doesn't have to generate code to handle ELF symbol interposition.

You might also want to compile with -fno-semantic-interposition since no one actually needs semantic interposition for symbols used and defined in the same library so you might es well disable it even or public functions.

And link with the `-Bsymbolic` or `-Bsymbolic-functions` linker options to save on the indirection when calling public functions within the same library but across object files.

These are non-standard GNU extensions, unfortunately.

All compiler flags are non-standard because the C standard does not concern itself with them at all.

That said, there are effectively two standard compiler interfaces: MSVC and GCC and everyone else emulates one or both of these.

Similarily, symbol visibility is not something that the C standard cares about because it doesn't even care about libraries in the first place. Again, for all platforms that have symbol visibility (e.g. PE and ELF based ones, although the details differ) there is a defacto standard for the compiler flags and attributes to control the visilibity: the MSVC and GCC extensions.

Actually, the only compiler interface that can claim to call itself a standard is POSIX c99. Everything else is too volatile to be a standard.

You can (and should!) use a linker version script instead to ensure you're not accidentally leaking any exported symbols from other static library dependencies ;)

Not surprising, though. The issues surrounding if/how a system provides libraries of any kind (static or shared) are completely implementation-defined. The Standard doesn't have anything to say about them at all except for the program-wide symbol scope rules.