this post was submitted on 07 Sep 2023
61 points (98.4% liked)

Programming

17484 readers
102 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi
61
How important is the option for dynamic linking (vs static linking) in the modern day? (lemmy.ml)
submitted 1 year ago* (last edited 1 year ago) by cyclohexane@lemmy.ml to c/programming@programming.dev
61 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] o11c@programming.dev 1 points 1 year ago (2 children)

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 points 1 year ago* (last edited 1 year ago) (1 children)

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 0 points 1 year ago* (last edited 1 year ago) (1 children)

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 points 1 year ago* (last edited 1 year ago)

Ah, yes, okay, that drama.

[–] ck_@discuss.tchncs.de 1 points 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.