5 ms·

It's not a sentiment, it's a question. I don't have an agenda here, I'm just trying to understand. > If all programs need to go through libc, doesn't that mean

It's not a sentiment, it's a question. I don't have an agenda here, I'm just trying to understand. > If all programs need to go through libc, doesn't that mean they are all equal? It means that all programs need to link libc into their binary, whether statically or dynamically. Part of the reason-de-etre for Rust seems to be as a replacement for C and C++ so it would seem peculiar to me that the C library would become a forced dependency for compiled languages like those. But as the other poster pointed out, you can disable it anyway, so no matter.

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 ago
  Say that to the plan9/9front users.
  - quotemstr 7y ago
    Ok. I will. So? Am I supposed to believe that a technique that works fine everywhere but Linux is somehow unworkable in general?

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 ago
Say that to the plan9/9front users.
- quotemstr 7y ago
  Ok. I will. So? Am I supposed to believe that a technique that works fine everywhere but Linux is somehow unworkable in general?