Launchpad 1.5.16 fails with glibc errors on RHEL 8

[surskitt]

When trying to run launchpad on RHEL 8, the following errors are returned:

./launchpad: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./launchpad)
./launchpad: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./launchpad)

This looks like a return of this issue: #417

Launchpad 1.5.15 runs with no issues. Has the new version of launchpad been built with dynamic libc linking again?

[james-nesbitt]

Interesting issue.

In a recent PR CI test run, we did run the "legacy suite" which includes both a Rhel8 manager and worker machine, and encountered no issued in the build nor the run.

In the smoke test we build the code, and then run it on aws ec2 machines.

[james-nesbitt]

Some more information for this issue:

1. we did switch our build system, moving away from go-releaser - which could be an issue
2. the smoke test that we run builds launchpad on an ubuntu machine

[james-nesbitt]

@surskitt confirmed: the new direct go build does not specify disabling cgo, so this is likely a regression.

[james-nesbitt]

Root cause identified and fixed in PR #639.

The release workflow's go build loop was missing CGO_ENABLED=0, so the v1.5.16 Linux binary was dynamically linked against the Ubuntu CI runner's glibc (2.32/2.34). On RHEL 8 (glibc 2.28) this produces the errors you're seeing.

The goreleaser config (.goreleaser.release.yml) was correctly setting CGO_ENABLED=0, but goreleaser is no longer used — the release workflow was rewritten to roll its own build loop and the flag wasn't carried over.

PR #639 adds CGO_ENABLED=0 to the build loop and removes the now-dead goreleaser config files. The next release build will produce a statically linked binary that runs on RHEL 8.

Written by AI: claude-sonnet-4-5

[james-nesbitt]

I am going to push for a fast tag release including only this (and perhaps some golang vendor updates for things like CVEs)