4 ms·

I think it's mainly that glibc has poor support for statically linking.

• tyingq 6y ago
  Ah, okay. Searched a bit, and it apparently requires you to find your own with dns client lookup library, avoid dlopen(), set GCONV_PATH, and so on.
  • aidenn0 6y ago
    For a long time glibc was maintained by someone who was of the opinion that if you wanted to statically link 3rd party libraries, then you shouldn't be allowed to build binaries.
    • asveikau 6y ago
      It's interesting because there is an opposite cult (I believe some prominent plan9 and go people are adherents) that believes dynamic linking should literally not be a thing. I even recall reading some essays that introduction of a dynamic linker was some kind of tragic downfall in Unix history. I think the truth is that both have costs and benefits. Dynamic linking is good for security patches, memory and disk usage. But it creates new opportunities for problems, for example ABI breakage becomes more significant of a problem and needs a lot of care to avoid. People distributing code, be it to end users or app stores or on servers with things like chroots, jails and containers, need to carry their dependencies anyway negating some of the benefits.
      • aidenn0 6y ago
        Note also that while it probably is a net-win for security to use dynamic linking, it's not 100% a win. I've seen security vulnerabilities introduced because of upgrades to dependencies.
        • tyingq 6y ago
          Well, and LD_LIBRARY_PATH type vulnerabilities.
  • loeg 6y ago
    In general, do not expect dlopen() to work in statically linked programs (in any libc).
    • deleted 6y ago
      [deleted]