hashicorp / hashicorp/nomad

Actual static linking / Not linking to glibc

Open
#5,643 19 comments 62 reactions 0 assignees View on GitHub
stage/needs-discussion theme/dev-environment type/enhancement
Dominant language
Go
Stars
17k
Forks
2.1k
Avg merge
1d 9h
Merged PRs (30d)
105

Description

Per suggestion in #5537 and encouragement from @angrycub, I'm opening this issue for the purpose of collecting thumbs-ups for building Nomad against non-glibc C libraries. As the binaries currently provided on https://nomadproject.io/ are not statically linked they only work if the machine they're running on has the correct version of glibc available.

Given that the Go way is to provide binaries that will run anywhere the CPU arch matches, I personally find this surprising. I find is even more surprising given that the effort to build in a container that contains an alternate C library is minimal.

While not getting into the justification of why one would run Nomad on a non-glibc platform as it is beyond the scope of this issue, some quick reasons that jump to mind from my own environments where muslc is the library of choice:

- muslc is a smaller and more correct implementation of the C Standard Library. Its very difficult to do something so badly in Go that a hard dependency on glibc is introduced, so artificially introducing the dependency by policy is an odd, and currently unjustified in writing, choice.
- Distribution provided packages aren't just for glibc (see the patches that @nilium is currently maintaining for Void Linux's builds)
- Nomad is distributed as a "static" binary, not a distribution package. Either Hashicorp supports distributions or they don't, but distributing a binary which should run on any Linux distribution, and then claiming that those distributions aren't supported is deceptive.
- muslc is the library of choice for building containers, and a number of distributions are now available that allow the benefits of musl to come to the metal. Given that the systems that nomad supervises tend to be minimal, it seems an obvious choice to pick a minimal system to run on the metal, thus maximizing Mhz and RAM available to tasks.

If builds without an artificial dependency on glibc is something that is important to you, please thumbsup this issue (or even just the support to create these builds on your own, as you should be able to do already but can't with the current release). Don't reply with a +1 as that just clutters the thread and makes your support difficult to track.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.