Hacker News Reader

Comment by electroly | Hacker News Reader

> incomplete dns resolving routines

They eventually did fix this, as of musl 1.2.4.

While not an issue for musl-centric distros if they keep updated, note that e.g. Debian stable doesn't have that version yet, so good luck testing.

At least we have light at the end of the tunnel now. This is a tremendous improvement from the previous status quo of the musl maintainers not even agreeing that it's a problem.

This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho

What's a better option for static linking? glibc is religiously against it; they have far worse dogmatic beliefs than this musl DNS thing. I'd be happy to choose a better alternative if one exists, but if one does not, I have to live with the options at hand. From where I'm standing, musl seems like the only game in town. uClibc doesn't seem like it's appropriate for general purpose Linux applications on desktop computers (maybe I'm wrong?).

Static linking doesn't actually solve any problem. Just use dynamic linking with (probably relative) rpath, and compile against a sufficiently old libc.

There's some common FUD about rpath being insecure, but that only applies if the binary is setuid (or otherwise privileged) and the rpath is writable by someone other than the binary's owner (all relative rpaths are writable since you can use symlinks; absolute rpaths are writable if they point to /tmp/ or a similar directory, which used to be common on buildbots).

This is really not hard; working around all static linking's quirks is harder.

What are the quirks of static linking you need to work around (in general, not for glibc)?

You have to know the internals of your dependencies so you can link them explicitly, recursively. (admittedly, pkg-config helps a ton, but not all libraries ship (good) .pc files)

Global constructors no longer reliably fire unless you are extremely careful with your build system, nor do they run in a predictable order (e.g. you can call a library before it is actually initialized, unlike dynamic linking where only preinit - which nobody uses - is weird), nor can you defer them until dlopen time if you want (which is, admittedly, overdone).

It's possible to link to parts of multiple versions of a library (remember, you have to recurse into your dependencies), as opposed to dynamic libraries where at least you're guaranteed all-or-nothing (which is much easier to detect).

Linking is slower since it always has to be redone from scratch.

Not resilent against system changes. For example, old versions of `bash-static` (grab them from e.g. Debian snapshot and extract them manually; don't install them) are no longer runnable on modern systems since certain system files have changed formats, whereas the dynamically-linked `bash` packages still run just fine.

It also encourages bad stability habits, leading to the equivalent of NPM hell, which is far worse than DLL hell ever was.

You can't use LD_PRELOAD or other dynamic interception tools.

There are probably more reasons to avoid static linking, but I'm trying to ignore the handful from the popular lists.

Thanks! Most of those seem like a fair trade-off for portability… for an app.

I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment!

Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".

The bash-static example alone is proof that the "usefulness" for apps isn't actually there.

> glibc is religiously against it

from my understanding glibc is not "religiously" against it, they're against it for technical reasons. In the sense, this is not a dogma. It's about internal details of their implementations.

See: https://stackoverflow.com/questions/57476533/why-is-statical...

Reply on news.ycombinator.com