Describe the bug
While building the amd64 container we are using the docker.io/golang:1.xx images which are presently based on debian 12 (glibc 2.36) with default settings to build the amd64 executables. This results in a dynamically linked executable being produced. We are then copying these executables into a ubi minimal base image based on rhel 9 (glibc 2.34).
This is probably asking for trouble, though I have not seen anything come out of this so far.
Inspecting the amd64 and arm64 images:
$ podman run --name debug-amd64 -it quay.io/skupper/service-controller:1.8.1 sh -c "exit 0"
$ podman cp debug-amd64:/app/service-controller amd64-service-controller
$ file amd64-service-controller
amd64-service-controller: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=tDoHpKoRMFpdnVEQWSWz/E8H1VyK6ir6DjPs1feRF/lHfHH4QI0RSIW-2ozsNB/Moz6mMTOFnYVz2zfMjPX, with debug_info, not stripped
$ podman run --name debug-arm64 --platform linux/arm64 -it quay.io/skupper/service-controller:1.8.1 sh -c "exit 0"
$ podman cp debug-arm64:/app/service-controller arm64-service-controller
$ file arm64-service-controller
arm64-service-controller: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=oaAf46oodUhuB2FoSzfT/FCYLVGOhyYBwY6YFLSgU/q2zcK7oQr0ffkH3LKAUP/0wowfXdMsmuAbTBRDus1, with debug_info, not stripped
Expected
I think that we should consistently set CGO_ENABLED=0, disabling cgo in the container builder stage to produce a pure go statically linked executable for all platforms. We have already taken similar steps for the skupper CLI.
Alternatively, we could explore using a debian 12 slim base image (although I lean towards keeping ubi9 minimal) or finding a rhel9 based go builder that keeps up with the upstream go releases rather than the redhat go toolset that tends to track a few versions behind.
Describe the bug While building the amd64 container we are using the
docker.io/golang:1.xximages which are presently based on debian 12 (glibc 2.36) with default settings to build the amd64 executables. This results in a dynamically linked executable being produced. We are then copying these executables into a ubi minimal base image based on rhel 9 (glibc 2.34).This is probably asking for trouble, though I have not seen anything come out of this so far.
Inspecting the amd64 and arm64 images:
Expected
I think that we should consistently set CGO_ENABLED=0, disabling cgo in the container builder stage to produce a pure go statically linked executable for all platforms. We have already taken similar steps for the skupper CLI.
Alternatively, we could explore using a debian 12 slim base image (although I lean towards keeping ubi9 minimal) or finding a rhel9 based go builder that keeps up with the upstream go releases rather than the redhat go toolset that tends to track a few versions behind.