build: new static make targets that disable CGO and exec driver

[pkazmierczak]

Nomad requires CGO on linux because of its dependency on nsenter. This dependency is used by the exec driver.

This changeset introduces an idea of providing a static make targets that disable CGO and thus the exec driver, providing "crippled" statically-linked builds.

$ echo $OSTYPE
darwin25
$ make dev-static
==> Formatting HCL
==> Removing old development build...
==> Building pkg/darwin_arm64/nomad with tags ui hashicorpmetrics  ...
$ GOOS=linux make dev-static
fork/exec /Users/piotrkazmierczak/Library/Caches/go-build/e9/e9d3b52d85779bd200d8b07f75552ee2baac6b49c8b465ad416a93b08df91839-d/main: exec format error
// more fork/exec errors...
// ...
==> Formatting HCL
==> Removing old development build...
fork/exec /Users/piotrkazmierczak/Library/Caches/go-build/e9/e9d3b52d85779bd200d8b07f75552ee2baac6b49c8b465ad416a93b08df91839-d/main: exec format error
// more fork/exec errors...
// ...
==> Building pkg/linux_arm64/nomad with tags ui hashicorpmetrics  ...
$ file pkg/linux_arm64/nomad
pkg/linux_arm64/nomad: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=ccb5edf4843fd127810037d93e3667b92a2bf749, with debug_info, not stripped
$ ls -lh pkg/linux_arm64/nomad
-rwxr-xr-x  1 piotrkazmierczak  staff   125M Dec 31 13:34 pkg/linux_arm64/nomad*

Verifying from Linux that we're not using CGO in the new target:

$ echo $OSTYPE
linux-gnu
$ make dev
==> Formatting HCL
==> Removing old development build...
==> Building pkg/linux_amd64/nomad with tags ui hashicorpmetrics  ...
$ ldd pkg/linux_amd64/nomad
	linux-vdso.so.1 (0x00007fff4f922000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073f795a00000)
	/lib64/ld-linux-x86-64.so.2 (0x000073f795c80000)
$ make dev-static
==> Formatting HCL
==> Removing old development build...
==> Building pkg/linux_amd64/nomad with tags ui hashicorpmetrics  ...
$ ldd pkg/linux_amd64/nomad
	not a dynamic executable

note to reviewers: While inelegant, this was the smallest change that achieved the desired effect. I think ideally we should untangle the executor package a bit more, separating the exec code away from qemu, java and raw_exec. Reliance on the Executor interface creates a bit of a maze of build flags as every developer that ever touched that package knows. But seeing as this is a dev-ex-only change, I didn't want to make it too big (renaming executor_linux.go to executor_linux_cgo.go was probably already a step too far, because we'll likely want to backport this to avoid merge conflicts...).

[jrasell]

It looks good to me from a code perspective. My slight fear is we make this area of code a little harder to understand and debug and fragmented a bit more.

I personally don't cross-compile on macOS and use build VMs and I don't think this will change that, so I'd be curious of other thoughts on the addition before a merge.

[tgross]

LGTM!

I thought that not having CGO would be a problem for shirou/gopsutil but at some point in their v3 version they managed to get rid of the remaining CGO.

[pkazmierczak]

Tagged a few other team members that use macOS, curious if others find this useful. If not, it makes no sense.

[pkazmierczak]

My slight fear is we make this area of code a little harder to understand and debug and fragmented a bit more.

Yeah :/

I personally don't cross-compile on macOS and use build VMs and I don't think this will change that, so I'd be curious of other thoughts on the addition before a merge.

Oh interesting. I struggle getting amd64 VMs on mac running, or running fast enough so that compilation isn't a huge pain. arm64 binaries are no good if feeding them to an e2e cluster, for example.

[mismithhisler]

What if we had a make target that ran a containerized build?

[allisonlarson]

Neat! I have had scenarios where I would find this useful, but I'm not sure about the tradeoff of added complexity for a build that isn't fully complete. If the question is just about the feature though, I think it'd be a handy tool under certain circumstances

[pkazmierczak]

What if we had a make target that ran a containerized build?

as in, with dockerx? to target different os types or architectures? I guess that'd be fine but I don't see much benefit of having it a make target as opposed to just running make dev inside a container.

I suspect building inside a container would be much slower. We'd have to build all the dependencies on every make.

[pkazmierczak]

There's another take on this: at the cost of disabling the exec driver, this offers statically-linked Nomad builds. So perhaps we could even rename the make target to static or sth? I can imagine scenarios in which people would enjoy having a statically linked binary at the cost of missing one driver which, just maybe, isn't the most popular of the drivers we offer.

[tgross]

There's another take on this: at the cost of disabling the exec driver, this offers statically-linked Nomad builds. So perhaps we could even rename the make target to static or sth? I can imagine scenarios in which people would enjoy having a statically linked binary at the cost of missing one driver which, just maybe, isn't the most popular of the drivers we offer.

I love this idea!

[tgross]

LGTM!