Programming

17417 readers

84 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

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@lemmy.nz

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

[–] ck_@discuss.tchncs.de 4 points 1 year ago (1 children)

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 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

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.

[–] 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.