David Edelsohn <dje....@gmail.com> added the comment:
Runtime linking allows a dynamically loaded library to interpose symbols. The classic example is allowing a program or dynamic library to overload C++ operator new. A library or program overrides the symbol by name. Python does not require this. Python does not need to allow an extension module to override a function in Python. If one needs to add AIX ld -G and runtime linking, 99% of the time one is covering up a problem. The downside of -G is that it forces all global functions to be called through the AIX glink code (equivalent to SVR4 PLT) and not inlined. This allows every global function call to be overriden, but forces every call to go through a function pointer. This is expensive. Calling functions through the "PLT" requires that the function pointers for each global function be placed in the AIX TOC (equivalent to SVR4 GOT). If the program or shared library is large enough, this can overflow the "GOT", which then requires even more expensive fixup code. The mistaken use of this option leads down a path with bad performance and potentially requiring more and more effort to recover from problems introduced by the choice. I don't know exactly the symptoms that you observed, but one possibility is that the shared object you are building is not being linked against all of the dependent libraries. Separate from runtime linking, SVR4 allows unresolved symbols when a shared library is created and used to export all global symbols by default (before the efforts on symbol visibility). A simplistic way of describing this is that a process into which an executable and shared libraries are loaded sort of has this soup of all global symbols floating around and available to the runtime loader. When a new shared library is loaded, the dynamic linker can resolve the symbols from any definitions available in the process. Allowing the unresolved symbols at shared library link time is a promise that the symbols will be provided by someone at runtime. At runtime, all of the symbol needs and definitions are thrown in the air and hopefully match up correctly when first referenced at runtime. AIX requires that all shared objects be fully resolved at link-edit time. It requires that the shared object refer to all dependent libraries at link time, even if those libraries also will be present and provided by other shared libraries or executable at runtime. In other words, on AIX, one must link all C++ shared objects against the C++ standard library, even if the main executable is linked against the library. So, again, one possible explanation for the error of missing symbols is that one or more dependent libraries are missing from the link command building the shared object and that omission coincidentally happens to work on SVR4/Linux because of its semantics, but it doesn't work in the more strict environment of AIX. This type of error should not be solved through runtime linking to borrow the missing symbols from the running process, which is a very expensive solution. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37690> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
