> I am curious whether other systems prefer a STB_GLOBAL definition to a STB_WEAK definition.
> We know that the dynamic linking design principle is "dynamic linking should be similar to static linking".
> However, I believe this sentence is ambiguous for this case, because I can use it to argue for either side.
The motivation for adding weak definitions to the gABI was to support
ANSI C namespace rules. We all needed our archive C libraries to be
able to contain a definition of, say, "open" or "close", without
intruding on the user's namespace. The problem was that even though
those symbols weren't part of the system's namespace (unless the
source code included a certain header file), they were still entry
points needed by other C library functions (like "fopen" and
"fclose"). We needed to be able to provide aliases (e.g., "_open" and
"_close") that could be used by the rest of the C library, in case the
user's program defined its own versions of "open" and/or "close",
while still making the plain names available to a program using the
This was a problem that existed only for archive libraries, and it was
a solution intended only for archive libraries -- in a shared library,
you can have regular definitions of "open" and "close" without causing
a multiple definition error, and as long as other functions in the
library bind to the internal entry points, there is no need for the
plain definitions in a shared library to be weak.
Weak definitions still managed to end up in shared libraries, but our
intent was that there would be no difference between weak and regular
In particular, the gABI speaks of weak definitions only in the context
of relocatable object files, and says this:
The behavior of weak symbols in areas not specified by this document is
Weak symbols are intended primarily for use in system software.
Applications using weak symbols are unreliable
since changes in the runtime environment
might cause the execution to fail.
The document revision history also has these notes:
(July 6, 1999) New language has been added warning about the use
of WEAK symbols in application programs.
(April 24, 2001) Changed the warning about using weak to be
stronger. [pun probably intended]
We really didn't want people mis-using STB_WEAK! (Not that those
warnings did any good.)
Weak references came along for the ride. We considered the behavior
useful, but it wasn't our primary motivation for adding STB_WEAK, and
we probably left it under-specified. But again, it was considered
useful only in the context of static linking. For dynamic linking,
users were supposed to call dlsym() if a symbol was optional. Our
failure to lock this down has been a rich source of bug reports due to
applications relying on unspecified, implementation-defined behavior.