3 ms·

The big reason on Linux is libc symbol versioning. You can inadvertently link to newer versions of glibc symbols if you don’t build on a platform using the olde

The big reason on Linux is libc symbol versioning. You can inadvertently link to newer versions of glibc symbols if you don’t build on a platform using the oldest libc you support. Go binaries have the advantage of being able to run on any Linux kernel they support, regardless of what distro and version they were built on. With Rust I usually end up having to compile a bunch of build-time dependencies from source on my build images because of this, instead of just using a version of Debian etc. new enough to have the right dependencies in the package repo. However I don’t think Go ‘s approach makes sense on some other platforms (e.g. macOS) that don’t suffer from this issue. In those cases you sacrifice forward compatibility for no real benefit.

quotemstr 8y ago
With the right linker script, you too can link against whatever symbol versions you want regardless of host OS. That it's annoying to do so is a minor problem with linker interfaces, not a fundamental error in the normal program execution model.
- johncolanduoni 8y ago
  I’m not sure where I said it was an error, let alone a “fundamental error in the normal program execution model”. It’s quite annoying either way you try to solve it; I haven’t used a linker script because then I have to hunt down each symbol version anytime I link a new symbol from glibc, instead of the future-proof setting up of an ancient build image once. If you’re writing a language forcing you to let the language compiler handle all linking of images is not a particularly user-friendly solution.
GordonS 8y ago
Yep, we have an ancient Ubuntu 7.04 build server for exactly this reason - linking against an old libc. This is how we've done it for something like 10 years now, and I've never thought about it since it works - but is there another approach we could use to link against an older libc version from a newer Ubuntu version?
- viraptor 8y ago
  Does the old libc not compile on the new system anymore? You could install it on the side, link to it, and fix up paths if needed.

quotemstr 8y ago

With the right linker script, you too can link against whatever symbol versions you want regardless of host OS. That it's annoying to do so is a minor problem with linker interfaces, not a fundamental error in the normal program execution model.

johncolanduoni 8y ago
I’m not sure where I said it was an error, let alone a “fundamental error in the normal program execution model”. It’s quite annoying either way you try to solve it; I haven’t used a linker script because then I have to hunt down each symbol version anytime I link a new symbol from glibc, instead of the future-proof setting up of an ancient build image once. If you’re writing a language forcing you to let the language compiler handle all linking of images is not a particularly user-friendly solution.

GordonS 8y ago

Yep, we have an ancient Ubuntu 7.04 build server for exactly this reason - linking against an old libc. This is how we've done it for something like 10 years now, and I've never thought about it since it works - but is there another approach we could use to link against an older libc version from a newer Ubuntu version?

viraptor 8y ago
Does the old libc not compile on the new system anymore? You could install it on the side, link to it, and fix up paths if needed.