If we made it work, we'd be more competitive with static-linkage-based toolchains.
-
-
Replying to @fche @CarlosODonell
We might be able to do some of this if we build the plt table into the static binary (to allow patching in calls from dlopened modules) and build all of libc.a in. It will end up bloating the binary big time though... It also may not work when the module needs a newer glibc.
3 replies 0 retweets 1 like -
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.
1 reply 0 retweets 0 likes -
The common use case is the naive expectation everything that works dynamically linked should work statically linked as well.
1 reply 0 retweets 0 likes -
I mean why replaceable PLT stubs would be needed. Dynamic linking never involves replacement of a symbol once defined.
1 reply 0 retweets 0 likes -
Those would be needed for indirect dependencies - i.e. the chain of dependencies of the dlopened lib.
1 reply 0 retweets 0 likes -
I don't follow..
1 reply 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
Unfortunately static ET_EXEC seems to lack dynsym table (or any _DYNAMIC), and gcc doesn't honor -rdynamic, but -Wl,--export-dynamic works.
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.