2 ms·
>>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynami
by Subsentient 6y ago
>>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static
I disagree, I tend to want the opposite. I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked, and OS facilities like libc to be statically linked.
- AnIdiotOnTheNet 6y ago> I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked These fall under "GUI" in the "base system" category in my opinion. > and OS facilities like libc to be statically linked. If you're not being sarcastic right now, I'm really curious as to your reasoning.
- zik 6y agoI'm not OP but statically linking a compact libc like musl gets you just the parts of libc that you need and nothing more. This can be a lot more efficient than a dynamically linked program which has to bring in the entire bloated mess of glibc. Whether this is a benefit when you're duplicating bits of libc across every executable in your entire system is unclear to me though.
- Subsentient 6y agolibc is much smaller than other libraries, and as another has pointed out, compiling it statically will get you only the symbols you actually use, so it doesn't even equal the total size of libc. Which makes more sense? Bloating your executable with ~100+MiB of Qt crap, or bloating it with 100KiB of libc symbols?