There was a time where this debate was bigger. It seems the world has shifted towards architectures and tooling that does not allow dynamic linking or makes it harder. This compromise makes it easier for the maintainers of the tools / languages, but does take away choice from the user / developer. But maybe that’s not important? What are your thoughts?

  • ck_@discuss.tchncs.de
    3·
    1 year ago

    Even if you do use static linking, you should NEVER statically link to libc

    This is definitely not sound. You should never statically link against glibc as glibc does some very unsound things under the hood like load NSS modules. Static linking against a non-bloatware libc is fine in most cases, as kernel interfaces break rarely, or rather, because Kernel devs go to extreme lenghts not to break user space, and they do a fantastic job too.

    • o11c@programming.dev
      11·
      1 year ago

      The problem is that GLIBC is the only serious attempt at a libc on Linux. The only competitor that is even trying is MUSL, and until early $CURRENTYEAR it still had worldbreaking standard-violating bugs marked WONTFIX. While I can no longer name similar catastrophes, that history gives me little confidence.

      There are some lovely technical things in MUSL, but a GLIBC alternative it really is not.

      • ck_@discuss.tchncs.de
        1·
        1 year ago

        The only competitor that is even trying is MUSL, and until early $CURRENTYEAR it still had worldbreaking standard-violating bugs marked WONTFIX.

        Can you share a link? I’d be genuinely interested.

        • o11c@programming.dev
          11·
          1 year ago

          DNS-over-TCP (which is required by the standard for all replies over 512 bytes) was unsupported prior to MUSL 1.2.4, released in May 2023. Work had begun in 2022 so I guess it wasn’t EWONTFIX at that point.

          Here’s a link showing the MUSL author leaning toward still rejecting the standard-mandated feature as recently as 2020: https://www.openwall.com/lists/musl/2020/04/17/7 (“not to do fallback”)

          Complaints that the differences are just about “bug-for-bug compatibility” are highly misguided when it’s useful features, let alone standard-mandated ones (e.g. the whole complex library is still missing!)

      • ck_@discuss.tchncs.de
        1·
        1 year ago

        I would not agree with the “only serious attempt” path. The problem that most other libc are not drop in replacements has little to do with standard compliance and a lot to do with the fact that software is so glued to glibc behavior that you would have to be bug for bug compatible to achieve that goal, which imo is not only unrealistic, it’s also very undesirable.