butane: Can't run fcct 04.0 standalone binary in alpine container

Hi,

I cannot run the latest release 0.4.0 binary inside an alpine container:

jens:~> docker run --rm -it alpine:3.8 sh
/ # wget -O /usr/local/bin/fcct https://github.com/coreos/fcct/releases/download/v0.4.0/fcct-x86_64-unknown-linux-gnu
Connecting to github.com (140.82.118.4:443)
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (52.216.170.59:443)
fcct                 100% |*******************************************************************************************************************************************************************************************| 10203k  0:00:00 ETA
/ # chmod a+x /usr/local/bin/fcct 
/ # /usr/local/bin/fcct 
sh: /usr/local/bin/fcct: not found

After installing file (using apk --update-cache --upgrade add file) it turns out the 0.4.0 release is a dynamically linked binary, not a static binary.

/usr/local/bin # file fcct
fcct: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, BuildID[sha1]=d9bb68fd48bf269bb0271cfc71545251d8fe1343, for GNU/Linux 3.2.0, stripped

Yet there aren’t any linker issues:

/usr/local/bin # ldd fcct 
	/lib64/ld-linux-x86-64.so.2 (0x7f40e5620000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f40e5620000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f40e5620000)

Shouldn’t the 0.4.0 release also be a statically linked binary? The 0.2.0 release is, and I can run that one just fine.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 5
Comments: 16 (12 by maintainers)

Most upvoted comments

Fixed in https://src.fedoraproject.org/rpms/butane/pull-request/5 for the next release. Thanks @Okeanos!

bgilbert on Jan 25, 2022

Yup, it’s on my radar and I’ll take a look when I can. Thanks for the PR.

bgilbert on Oct 7, 2021

@bgilbert thank you for the pointers; I had another look at this:

The butane.spec relies on go-rpm-macros and specifically uses the gobuild macro to build the linux binaries for each invoked architecture. However, there’s no way to set CGO_ENABLED to any value with gobuild aside from abusing the gomodulesmode flag. Also as far as I understand the ldflags and extldflags, they would nullify this. There’s a stackoverflow thread proposing a solution and golang/go#41944 but I am not sure that’s a maintainable solution here.

The option you proposed appears to be the easiest right now, i.e. add additional gocrossbuild calls for Linux for each arch with CGO_ENABLED=0. “Optimising” the build flags within the macros, potentially affecting lots of other projects, doesn’t strike me as a good option. An alternative would be replacing the gobuild call with a plain go build as well; similar to the gocrossbuild – after all butane doesn’t appear to be using any fancy CGO or other dependencies that would require this massive list of ldflags and build optimisation?

As I don’t have a Fedora account, I am not sure I can contribute these changes right now.

Okeanos on Sep 16, 2021

Whoops, yeah, sorry, I know what’s going on. For policy reasons, our release binaries are built in Koji from the Fedora specfile, and of course the Fedora build macros produce dynamically-linked binaries. Probably the right approach is to extend the nonlinux subpackage to include static versions of the binary for all architectures we ship.

bgilbert on Sep 16, 2021