The part about weak symbols is wrong, at least on modern systems in their default configuration.
Weak symbols only work for linking (ld). They do not work at load time (ld.so). The result of this is that weak symbols are mostly only useful in loose objects or static libraries (though I think the strong symbol can be from a shared library if you're careful).
Also, the original problem description is incomplet - even if the public ABI is identical, multiple copies of a shared library can cause problems due to multiple copies of private globals, or due to different internal ABI. These are usually a problem when mixing versions, where most symbols bind to the old library but newly-added symbols necessarily only bind to the newer library.
> People still don’t agree if shared libraries are a net win or a net loss as a concept :)
After decades of preferring shared libraries a friend quickly convinced me to flip a few years ago. Nowadays the benefits aren't worth the hassles and disk space is cheap (reduced object file size used to be a big deal when system disk sizes were measured in tens of MB or even KB).
Even a static binary almost always needs to be dynamically linked to the system libraries so the OS can be updated.
Weak symbols only work for linking (ld). They do not work at load time (ld.so). The result of this is that weak symbols are mostly only useful in loose objects or static libraries (though I think the strong symbol can be from a shared library if you're careful).
Also, the original problem description is incomplet - even if the public ABI is identical, multiple copies of a shared library can cause problems due to multiple copies of private globals, or due to different internal ABI. These are usually a problem when mixing versions, where most symbols bind to the old library but newly-added symbols necessarily only bind to the newer library.