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 …
-
-
Replying to @CarlosODonell
If we made it work, we'd be more competitive with static-linkage-based toolchains.
1 reply 0 retweets 0 likes -
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 -
Replying to @siddhesh_p @fche
Yes, but you'd have to revert useful optimizations in the static binary and keep PLTs present. It would be tough. Basically it ends up looking a lot like a dynamically linked binary that has been statically assembled and can later be relinked. It's not easy.
1 reply 0 retweets 1 like -
There are a lot of inherent problems with static linking and dlopen, stemming from the partial inclusion of any given library that turns library-internal interface surfaces into external ones.
1 reply 0 retweets 1 like -
Replying to @RichFelker @CarlosODonell and
I see two possible consistent approaches to dlopen with static linking, either...
1 reply 0 retweets 0 likes -
Replying to @RichFelker @CarlosODonell and
1/2) Have dlopen ignore and treat as already-opened any .so providing definitions of symbols already static linked. This means you need --whole-archive for these if you want additional symbols available at runtime.
2 replies 0 retweets 0 likes
2/2) Don't actually do static linking, just package all the .so's in one big ELF file.
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.