4 ms·

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 choos

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?).

o11c 3y ago
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.
- schemescape 3y ago
  What are the quirks of static linking you need to work around (in general, not for glibc)?
  - o11c 3y ago
    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.
    - schemescape 3y ago
      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".
      - o11c 3y ago
        The bash-static example alone is proof that the "usefulness" for apps isn't actually there.
        deleted 3y ago
        [deleted]
        deleted 3y ago
        [deleted]
znpy 3y ago
> 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-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...

o11c 3y ago

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.

schemescape 3y ago
What are the quirks of static linking you need to work around (in general, not for glibc)?
- o11c 3y ago
  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.
  - schemescape 3y ago
    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".
    - o11c 3y ago
      The bash-static example alone is proof that the "usefulness" for apps isn't actually there.
      - deleted 3y ago
        [deleted]
      - deleted 3y ago
        [deleted]

znpy 3y ago

> 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-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...