What is the difference between a binary built with CGOENABLED=0 from the default mode?

[Jhonathan_Cavalcante]

I was facing a issue accessing a golang binary inside an alpine container. Aparently the use of some C libraries was lacking from my binary I suppose. Alpine /bin/sh couldn’t find my app binary as a ENTRYPOINT for a Dockerfile.

I managed to fix it adding to the go build command the following variable and flag:

CGO_ENABLED=0
-installsufix cgo

I managed to fix the issue and the container started to work properly, but I’m not sure why. I’ve checked the docs around CGO, and I understood that the usage of cgo enables the use of C code as a Golang package. My question is how does it especifically transform a Go binary? How can I check what’s different on the enable/disabled binary file output?

I supose that enabled CGO induced the /bin/sh of alpine to require some modules/libs to be able to find or execute the binary, but it seens blur to me how to approach it.

[Metalymph (lorenzo pirro)]

I think the answer is This as I suspected…gcc paths.

[Jhonathan_Cavalcante]

Thanks for the answer @Metalymph ! I’ve could understand it better with your reading sugestion.

[caster]

glibc depedency