Hacker News Reader

Comment by dataflow | Hacker News Reader

Statically link everything? Including glibc?

When trying to statically link everything, glibc is not as much a problem as GPU drivers are if you want binaries that work on more than one system

> Including glibc?

Any reasonable person doing this would use Musl of course.

And then you discover your program can't resolve hostnames because "DNS responses shouldn't be that big".

Can you explain how musl is related to this DNS resolving problem?

https://news.ycombinator.com/item?id=28312935

But honestly, they really shouldn't.

Trick question: glibc doesn't support that.

Trying to statically link with glibc is a fool's errand.

glibc doesn't support static linking, but you can fully static link with another libc if that is what you wanted to do.

Not that it is needed for forward-compatible Linux binaries since newer glibc versions are backwards compatible so dynamically linking the oldest one you want to support works fine. Would be nice if glibc/gcc supported targetting older versions directly without having to have an older copy installed but that is a convenience issue.

AppImage is sufficient.

nope, it still requires at least the glibc version that the appimage was compiled against. snaps, flatpaks nor appimage solve the long-standing glibc versioning issue that plagues portable Linux binaries. the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header

> the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header

Or just compile against an older glibc version. Plenty of tools to setup sysroots for that, e.g. https://wiki.gentoo.org/wiki/Crossdev

Reply on news.ycombinator.com