v4.1.0 static binary is windows not linux

[gmarcy]

Discussed in #14200

^{Originally posted by gmarcy May 11, 2022}

# file v4.*/podman-remote-static
v4.0.2/podman-remote-static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=b604c7916365eac339ca59b169b1c252d35f53d5, for GNU/Linux 3.2.0, not stripped, too many notes (256)
v4.1.0/podman-remote-static: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

[gbraad]

Which steps did you take to determine this?
Is this from what you found in a download folder?

I do not observe an issue when using make cross and make podman-remote-windows.

[gmarcy]

downloaded the release artifact

wget https://github.com/containers/podman/releases/download/v4.1.0/podman-remote-static.tar.gz

[Luap99]

@mheon PTAL I think we had the same problem before?

[randombenj]

I encountered the same problem, and I get #13557 when using 4.0.2 which is the latest Linux static binary. So 4.X is not really usable for me on linux :)
4.X has some really great features! But it is not entirely clear how one should install it, as the repos in https://podman.io/getting-started/installation still only provide 3.X versions and the static binaries seem to be broken. Is there any official 4.X installation guide?

[mheon]

mheon@Marlborough code/podman $ file bin/podman-remote-static
bin/podman-remote-static: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

Yep, that's definitely Windows.

I built the artifacts with the following command:

make podman-remote-release-darwin_amd64.zip podman-remote-release-darwin_arm64.zip podman-remote-release-windows_amd64.zip podman-remote-static podman.msi

make podman-remote-static seems to work on its own, so current best guess is that the podman-remote-release targets are polluting the environment somehow (environment variables, I'd guess?) such that it's generating a Windows binary.

Let's see if changing the order they're built in is a temporary fix...

[mheon]

Changing the order does not resolve the problem; seemingly one of the later targets either removes it, or it's not built at all. Fun.

[rhatdan]

@mheon Can you force a fix up to github?

[mheon]

We should get a fix into the Makefile first so this does not happen again. I'll see what I can do about that.