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 see two possible consistent approaches to dlopen with static linking, either...
-
-
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.
-
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.
-
I think that covers making in consistent. The remaining part is whether it meets people's needs.
-
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 …
-
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.
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.