←back to thread

The state of binary compatibility on Linux and how to address it

(jangafx.com)
196 points generichuman | 6 comments | 01 Apr 25 22:22 UTC | HN request time: 0.606s | source | bottom
Show context
Jeaye ◴[02 Apr 25 00:21 UTC] No.43552616[source]▶
I don't understand why they don't just statically link their binaries. First, they said this:

> Even if you managed to statically link GLIBC—or used an alternative like musl—your application would be unable to load any dynamic libraries at runtime.

But then they immediately said they actually statically link all of their deps aside from libc.

> Instead, we take a different approach: statically linking everything we can.

If they're statically linking everything other than libc, then using musl or statically linking glibc will finish the job. Unless they have some need for loading share libs at runtime which they didn't already have linked into their binary (i.e. manual dlopen), this solves the portability problem on Linux.

What am I missing (assuming I know of the security implications of statically linked binaries -- which they didn't mention as a concern)?

replies(6): >>43552647 #>>43552652 #>>43552691 #>>43552703 #>>43552800 #>>43552822 #
masfuerte ◴[02 Apr 25 00:28 UTC] No.43552647[source]▶
Various things including name (DNS) resolution rely on dynamic linking.
replies(1): >>43552651 #
1. Jeaye ◴[02 Apr 25 00:30 UTC] No.43552651[source]▶
Are you saying that a statically linked binary cannot make an HTTP request to `google.com` because it would be unable to resolve the domain name?

There are entire distros, like alpine, built on musl. I find this very hard to believe.

replies(4): >>43552683 #>>43552699 #>>43552733 #>>43555012 #
2. masfuerte ◴[02 Apr 25 00:36 UTC] No.43552683[source]▶
The configuration of DNS resolution on Linux is quite complicated [1]. Musl just ignores all that. You can build a distro that works with musl, but a static musl binary dropped into an arbitrary Linux system won't necessarily work correctly.

[1]: https://news.ycombinator.com/item?id=43451861

3. Spivak ◴[02 Apr 25 00:40 UTC] No.43552699[source]▶
You have to bundle your own resolver into your application. But here's the rub, users expect your application to respect nsswitch which requires loading shared libs which execute arbitrary code. How Go handles this is somewhat awkward. They parse /etc/nsswitch and decide if they can cheat and use their own resolver based on what modules they see[1]. Otherwise they farm out to cgo to go through glibc.

[1] They're playing with fire here because you can't really assume to know for sure how the module 'dns' behaves. A user could replace the lib that backs it with their own that resolves everything to zombo.com. It would be one thing if nsswitch described behavior which was well defined and could be emulated but it doesn't, it specifies a specific implementation.

replies(1): >>43552720 #
4. Jeaye ◴[02 Apr 25 00:45 UTC] No.43552720[source]▶
Fascinating. Thanks for breaking this down more. I think the article could've explained this point further.
5. o11c ◴[02 Apr 25 00:46 UTC] No.43552733[source]▶
All versions of MUSL prior to 1.2.4 (released less than two years ago) would indeed fail to perform DNS lookups in many common cases, and a lot of programs could not run in MUSL as a result. (I'm not aware of what specific deficiencies remain in MUSL, but given the history even when there are explicit standards, I am confident that there are more.) This wasn't related to dynamic linking though.

Glibc's NSS is mostly relevant for LANs. Which is a lot of corporate and home networks.

6. thyristan ◴[02 Apr 25 09:36 UTC] No.43555012[source]▶
The easy and conforming way to do that would be to call "getent hosts google.com" and use the answer. But this only works for simple use cases where you just need some IPv4/IPv6 address, you can't get other kinds of DNS records like MX or TLSA this way.