3 ms·
Linking libc dynamically is essentially free. Every program on the system runs it, so almost all its code and clean data pages are already in memory. As for st
by quotemstr 7y ago
Linking libc dynamically is essentially free. Every program on the system runs it, so almost all its code and clean data pages are already in memory.
As for static libc: please don't do this. A static libc, from a compatibility POV, is just as bad as embedding random SYSENTER instructions in program text. It makes the system much more brittle than it would otherwise be. I understand the desire to package a whole program into a single blob that works on every system, but we should support this use case with strong compatibility guarantees for libc, not with making SYSENTER the permanent support boundary!
When I am god emperor of mankind, on my first day, I will outlaw both static linking of libc and non-PIE main executables.
- nineteen999 7y ago> As for static libc: please don't do this. Preaching to the converted here, I'm a big fan of dynamic linking. It seems that while Go binaries are generally statically linked (last time I checked, which was a while ago), that libc is generally dynamically linked for the reasons that you have stated, also also because some features like NSS require dynamic linking to work correctly. Disclaimer: I mostly program in C and C++, not Rust or Go (yet).
- anthk 7y agoSay that to the plan9/9front users.
- quotemstr 7y agoOk. I will. So? Am I supposed to believe that a technique that works fine everywhere but Linux is somehow unworkable in general?