Ahmad Khalifa <ah...@khalifa.ws> writes: > But reading that, I don't see how the linker could declare a dynamic > GLIBC_ symbol without the related library reference.
> In fact, it should choke with "undefined reference" long before outputting > a .so file. Even when compiling with -nolibc. But there is always a > special case somewhere :) Historically, it happened with plugins that were built with the Libtool -module flag or the underlying equivalents, which allows creation of a shared library module with undefined references. This is (or at least was) normal behavior for modules meant to be opened with dlopen; the symbols are resolved at dlopen time from the program that is importing the module. This is desired behavior when the symbols are coming from the program, but it is (or at least was) easy to accidentally leave libc symbols undefined as well, in which case they too are resolved from the main executable at dlopen time. My recollection (it's been a *lot* of years so I'm hoping I'm getting this right) is that this interfered with proper symbol versioning and could cause the symbols to be resolved weirdly in a way that could cause serious bugs. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
