4 ms·

In a sense, yes - specifically if libc could be link-time inlined. I don't think many people are proposing that for libc though because it would shut down the

In a sense, yes - specifically if libc could be link-time inlined. I don't think many people are proposing that for libc though because it would shut down the possibility to patch libc for anything that has been link-timed inline, and more generally expose the internal implementation of libc in a way that will make evolving it very difficult. That is, link-time inlining will see a lot more use within an application before it will ever apply to system libraries.

quotemstr 7y ago
Applying LTO to libc would be no worse than statistically linking it. I don't like static linking, but on Linux, we're stuck with supporting it.
- gpm 7y ago
  Isn't glibc almost always dynamically linked on linux? I thought half the point of musl was that it supported static linking.
  - quotemstr 7y ago
    Almost everyone does dynamically link Glibc. You should dynamically link glibc too. But if you really want, you can statically link glibc. $ dpkg -S '*/libc.a' libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a But please don't. Static linking doesn't give you a compatibility advantage: dynamically linked glibc is specifically designed to be forward and backward compatible. Static linking only makes life more difficult later, since it complicates use of NSS and PAM and precludes nice, clean shims between user and kernel mode. Seriously. It was a mistake for Linux to make the kernel-user transition the stable system ABI instead of putting that stability boundary at the libc layer like most other operating systems. As for static linking being a competitive advantage of musl: I don't know where you got that idea. Musl is less featureful than glibc, not more. In particular, I'm not going to use it until it supports dlclose like every other full-featured computing platform.
    - gpm 7y ago
      > As for static linking being a competitive advantage of musl: I don't know where you got that idea. That's how I've been told to build fully statically linked rust binaries, I can't say I've dug into why glibc isn't used for those.
      - glandium 7y ago
        The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc because chances are you're going to be using symbols that aren't available in older versions of the glibc, making your binary incompatible with many (older) distros. musl is an easy way out of that. Another is to build against an old glibc.
        quotemstr 7y ago
        The right way to solve this problem would be to teach the linker to link against the set of glibc symbols that existed as of a particular version number or date. Then you'd just pass a flag (along with a preprocessor macro, so the headers would know to define the right version of the linker symbols) specifying this version target when you built your program. For want of this relatively simple toolchain feature, we have people statically linking entire C libraries. It's a shame. You can do a moral version of the same thing using linker scripts, but nobody bothers with linker scripts.
        glandium 7y ago
        The macOS SDK does this better. It is indeed a shame that the glibc doesn't care.
      - JoshTriplett 7y ago
        The primary reason is that a statically linked glibc can't use NSS (Name Service Switch) modules from a different glibc version, so if you statically link glibc you can't reliably resolve names with getaddrinfo. You can do DNS with other libraries, and many applications do anyway because they want asynchronous DNS and NSS uses static DNS, but you can't really do anything other than DNS or static hosts files. musl, on the other hand, never supports NSS, whether static or dynamic, and exclusively supports DNS. You can't resolve things like mDNS names, or even resolve localhost if on a system that doesn't hardcode it in /etc/hosts. So either way, static linking and name resolution don't mix well, and musl and non-DNS name resolution don't mix well.
goalieca 7y ago
True, static linking would be troublesome but what about at load time? Dynamic link time optimization could be very useful.

quotemstr 7y ago

Applying LTO to libc would be no worse than statistically linking it. I don't like static linking, but on Linux, we're stuck with supporting it.

gpm 7y ago
Isn't glibc almost always dynamically linked on linux? I thought half the point of musl was that it supported static linking.
- quotemstr 7y ago
  Almost everyone does dynamically link Glibc. You should dynamically link glibc too. But if you really want, you can statically link glibc. $ dpkg -S '*/libc.a' libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a But please don't. Static linking doesn't give you a compatibility advantage: dynamically linked glibc is specifically designed to be forward and backward compatible. Static linking only makes life more difficult later, since it complicates use of NSS and PAM and precludes nice, clean shims between user and kernel mode. Seriously. It was a mistake for Linux to make the kernel-user transition the stable system ABI instead of putting that stability boundary at the libc layer like most other operating systems. As for static linking being a competitive advantage of musl: I don't know where you got that idea. Musl is less featureful than glibc, not more. In particular, I'm not going to use it until it supports dlclose like every other full-featured computing platform.
  - gpm 7y ago
    > As for static linking being a competitive advantage of musl: I don't know where you got that idea. That's how I've been told to build fully statically linked rust binaries, I can't say I've dug into why glibc isn't used for those.
    - glandium 7y ago
      The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc because chances are you're going to be using symbols that aren't available in older versions of the glibc, making your binary incompatible with many (older) distros. musl is an easy way out of that. Another is to build against an old glibc.
      - quotemstr 7y ago
        The right way to solve this problem would be to teach the linker to link against the set of glibc symbols that existed as of a particular version number or date. Then you'd just pass a flag (along with a preprocessor macro, so the headers would know to define the right version of the linker symbols) specifying this version target when you built your program. For want of this relatively simple toolchain feature, we have people statically linking entire C libraries. It's a shame. You can do a moral version of the same thing using linker scripts, but nobody bothers with linker scripts.
        glandium 7y ago
        The macOS SDK does this better. It is indeed a shame that the glibc doesn't care.
    - JoshTriplett 7y ago
      The primary reason is that a statically linked glibc can't use NSS (Name Service Switch) modules from a different glibc version, so if you statically link glibc you can't reliably resolve names with getaddrinfo. You can do DNS with other libraries, and many applications do anyway because they want asynchronous DNS and NSS uses static DNS, but you can't really do anything other than DNS or static hosts files. musl, on the other hand, never supports NSS, whether static or dynamic, and exclusively supports DNS. You can't resolve things like mDNS names, or even resolve localhost if on a system that doesn't hardcode it in /etc/hosts. So either way, static linking and name resolution don't mix well, and musl and non-DNS name resolution don't mix well.

goalieca 7y ago

True, static linking would be troublesome but what about at load time? Dynamic link time optimization could be very useful.