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 -
Yeah that's what my idea was, I guess I didn't do a good job of expressing it ;) You would still need a truckload of constraints to make it consistent.
1 reply 0 retweets 0 likes -
I think that covers making in consistent. The remaining part is whether it meets people's needs.
1 reply 0 retweets 0 likes -
We have already discussed policy on this. I expect static linking in the future will not support dlopen, and we will fix everything else to work with static linking. This way you cant make a broken program. https://www.sourceware.org/ml/libc-alpha/2017-12/msg00831.html …
2 replies 1 retweet 1 like
That may work for glibc where static linking is frowned upon, but for musl static dlopen is a much-requested feature and I think we can make it work reasonably and consistently.
-
-
I am a staunch proponent for having static linking available as an option, but I'd like to see a working subset that is robust. I applaud your efforts to support static linking *and* dlopen.
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.