PSA: Static linking and threads has never worked with the GNU toolchain, it was always a limited use scenario and developers ignored the warnings. It doesn't work 100%. Still in draft form for Fedora C/C++ guidelines: https://fedoraproject.org/wiki/C_and_C%2B%2B_v2#Static_Linking …
I don't see why that should be needed or how it would work reliably unless it's acceptable that arbitrarily many threads are still executing the old versions arbitrarily long into the future after dlopen.
-
-
The common use case is the naive expectation everything that works dynamically linked should work statically linked as well.
-
I mean why replaceable PLT stubs would be needed. Dynamic linking never involves replacement of a symbol once defined.
-
Those would be needed for indirect dependencies - i.e. the chain of dependencies of the dlopened lib.
-
I don't follow..
-
The dependencies for a dlopened lib are often not known until runtime, so we'll need the PLT trampolines to allow access to the symbols inside the static binary.
-
Yes the dlopened lib needs to be able to see syms from the static linked program but that doesn't require plt in main program, just in the lib as usual.
-
Unfortunately static ET_EXEC seems to lack dynsym table (or any _DYNAMIC), and gcc doesn't honor -rdynamic, but -Wl,--export-dynamic works.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.