Documentation does not mention Windows binary of Skopeo.

[tandeday]

A quick read of the documentation did not immediately reveal how I got a Windows (10 if that matters) binary of skopeo for me to use against our OpenShift cluster. I do not have Go experience so I didn't just go ahead and build it.

It would be nice if the documentation clearly stated:

• If a binary is available for download (probably isn't).
• How to create one if possible? (along with a difficulty estimage).
• If not possible within reason, then explicitly mention that.

Thanks

/Thorbjørn

[vrothberg]

Hi @m86194, thanks for opening this issue.

We don't offer binaries for any OS. Skopeo is (build) tested against Linux and Mac OS but I am not sure how far we can come on Windows. I don't have access to a Windows machine for testing.

@mtrmac @rhatdan WDYT?

[mtrmac]

We do test Windows cross-compilation of c/image, so it is probably buildable, but I wouldn’t be at all surprised if Skopeo were a pretty bad Windows citizen (WRT configuration file paths and the like), and not extremely surprised if it were broken due to different path syntax or the like (though there was at least one Windows-based user of the c/image library at one point).

make binary-local would be the default way to try to build it, adding some BUILDTAGS might be necessary.

Frankly, making Windows work, and work smoothly, and having everything well documented, would be mostly dependent on someone interested contributing that. We are definitely interested, at least enough not to sabotage that :) , but lack both access and time to do it ourselves.

Same for providing pre-built binaries; on Linux it is more or less an intentional choice not to, because a single binary is not portable to various Linuxes; on Windows it might be more practical, but again dependent on someone integrating that into the current build system.

[xphyr]

SO, it very much seems possible. I was able to build a Windows binary just this evening (completely unrelated to @m86194 request). I made a small tweak to the Makefile (created a Windows build target) and it does compile. I will test it out tomorrow at work on a Windows machine and see if its usable. If you are curious about the addition to the Makefile take a look at my fork of this project.

[tandeday]

First of all, please notice I am not requesting a windows build (which would be nice, though) but that the documentation is clearer about what can be expected from a new user coming to the project. (I need a dockerless image mirrorer) because it is slowly showing up in google searches for this kind of utility.

I fully understand that you have limited resources and this is to be considered an internal Redhat tool which just happens to be useful to others, instead of a fully funded product. I am just letting you know that people like me want to know this pretty quickly when triaging posibillities.

@xphyr this sounds very interesting. If it is usable, I'd like to have a look at it. Thanks.

[rhatdan]

Well, first of all this is not an Internal Red Hat Tool. Skopeo is a fully open source project and we welcome it running on any platform. Linux, MAC, Windows ...

If we get contributors working on the Windoews and MAC Ports that would be great. The primary developers right now are Linux users and therefore it gets the most attention.

We are working to make Podman easier to consume on Windows and MAC, so I don't see a reason why we would not want to get Skopeo easily available on those platforms as well.

[xphyr]

I was able to test the windows binary and it works for what we needed (doing remote inspection of images). From an initial look, I believe the Mac Port and Windows port would be similar in nature, leveraging the "binary-static" targets in the Makefile to eliminate anything that requires CGO or linux only features like brtfs. I will take some additional time over the next few days to try and test the other functionality of the tool on these non-linux OSes.

[rhatdan]

Great, thanks for looking into this.

[xphyr]

Over the weekend I tested the functionality of the Windows and OSX builds, using the Make file in my fork and I documented the results in the readme as well. Generally speaking, inspect, copy & delete work, as does the various storage subsystems except those specifically tied to the linux operating system (such as "ostree support"). It looks like this was known for OSX, but not for Windows.

If there is interest, I would be happy to work on a binary release process for OSX/Windows so that others could leverage this tool on alternative platforms without the need for installing Go and Make. My first thought would be to either use either:

• goreleaser as part of the Travis CI build process
• the native TravisCI release module.

Please let me know if this is something you would like to accept into the project and I will work on putting it together.

[rhatdan]

Yes, I think we are very interested in this.

[vrothberg]

Absolutely, thanks for looking into this, @xphyr !

[xphyr]

I have been able to make relatively few changes to the build process and I now have a travis build that runs against Linux, OSX and Windows and passes all tests successfully. I am now working on how to get travis to create a github "release" so that we can upload a compiled binary for windows and osx. The on-going work is in my fork if anyone is interested in seeing progress or has any feedback.

[mtrmac]

Great!

Some quick observations looking at that branch (without checking to verify that what I’m talking about is practical right now, it may just be my ignorance):

• If possible, I’d like to minimize proliferation of build targets, and rule duplication; e.g. the primary make binary-local target, when run on macOS/Windows, should automatically produce a working macOS/Windows binary, and we shouldn’t need to tell the users to run different commands on different systems. (Your work already moves in this direction, with the OS/name conditionals). cross-OS build targets may still be useful, but they are distinctly secondary to native builds, and ideally should reuse, not duplicate, the primary build rules (e.g. a binary-local-windows target could just be make binary-local OS=Windows_NT or something like that).
• We’re, by default, emphasizing the non-container builds (make binary-local); if they work, and they are the only ones used by CI, I’m not sure we even need the container ones to be added; they bring little value and are somewhat likely to be broken without anyone noticing.
• At least on Linux, the default is to use dynamic, not static, linking, unless there is a good reason (dynamic linking is preferred to allow independent updates of the called libraries, including security fixes). I’m not sure whether this applies to macOS/Windows as well (I don’t know all that much about them) – it may well not be the same – but I’d like this to be, eventually, at least explicitly discussed.

[xphyr]

Thanks @mtrmac for the feedback. I agree the multiple build targets was getting a bit much, and I really like your solution. I will look to incorporate this into the work I am doing. I will need to look more into static vs dynamic linking on macOS/Windows. I will admit ignorance here and say that I have only ever built static binaries for these OSes. One of the things that has made building the Windows binary more challenging is the CGO requirement for gpgme in the containers/image library. I may look into this next, just to see if there is a solution to this problem as my next project to tackle ...

[xphyr]

End of the weekend update, my football team lost, but I was able to clean up the multiple build targets, and make "make" do something much more sane. I am now detecting the need for "containers_image_openpgp" dynamically, similar to the detection of OSTREE, LIBDM and BTRFS tags. This has us back to just "binary-local" and "binary-local-static" targets. I have also backed out the explicit requirement to build static and the BUILD_OS is auto-detected on start, but can be over-ridden for testing purposes.

I also had success in publishing a Windows and OSX build binary to my fork. I have done a preliminary test of the Windows binary and it works. If you check my fork under releases you will see a Windows and OSX (darwin) release file for version 0.1.40-xphyr.

I am wondering if I should tackle #580 while I am in the Makefile making changes. After reading 580, as well as the comments above about not needing containers should I attempt to strip the container build targets from the Makefile, or do we want to do that as a separate PR (if at all).

[sebastianwebber]

hello all!

do you guys still have an interest to use GoReleaser to make the releases? Can I open a PR?

[TomSweeneyRedHat]

@sebastianwebber we're interested, @xphyr have you made any further progress?

[sebastianwebber]

hey @TomSweeneyRedHat and @xphyr I added a draft PR but i need some info to finish.

[xphyr]

Hello all, sorry I must be honest, I completely forgot about this. We got a version working for windows for my prior employer using my fork and then I had to move on... my fork is very outdated so I should really go back and take a look at if my make file changes would still work. Using GoReleaser is a good idea and I could take a look at what what @sebastianwebber has put together for it ... the question becomes does the skopeo project want to take on a different build process or stick with "make"... (BTW I am now a Red Hatter (yeah!) so I can hopefully see this through to completion now. )

I think what I need to know is if we want to incorportate fixes for #580 as well as getting a windows build working and getting binary releases out there or not.

[TomSweeneyRedHat]

@xphyr welcome to Red Hat! @mtrmac and @vrothberg 's call, but I'd like to stick with make if we can. But if it turns out it's not possible to pull off a windows build that way, I'd not be against a separate build.

@xphyr did you want to tackle #580? If not, we probably can twist @parkervanroy 's arm and ask him to take a look.

[TomSweeneyRedHat]

and I'll try using Parker's real GitHub handle this time, @ParkerVR. Parker please see the above comment.

[ParkerVR]

@TomSweeneyRedHat happy to look into this, but I don’t have much bandwidth this week and am moving next week- can get into it after that.

[xphyr]

@TomSweeneyRedHat thanks for the welcome .. who knew a year ago I would be here! I will take a look at both the windows build as well as tackling #580 I have not looked at this in a while, so will take me a few minutes to get back up to speed. I will status this issue later in the week with where I have gotten.

[rhatdan]

@ParkerVR Stick to the shortnames work.

[rhatdan]

@ashley-cui PTAL

[awakecoding]

Is this still being worked on? I'm not a Go dev, but I just tried running "go build" in "skopeo\cmd\skopeo", and it fails with the following:

# github.com/mtrmac/gpgme
cgo: exec gcc: exec: "gcc": executable file not found in %PATH%
# github.com/miekg/pkcs11
cgo: exec gcc: exec: "gcc": executable file not found in %PATH%
# github.com/containers/storage/pkg/unshare
cgo: exec gcc: exec: "gcc": executable file not found in %PATH%

I'm surprised that Go packages try calling gcc directly, but has anyone managed to get a Windows build, and if so, how?

[lsm5]

@TomSweeneyRedHat @rhatdan does a pre-packaged windows binary exist?

[awakecoding]

I just tried building podman as well and it fails for exactly the same packages, reading a bit more about it, it looks like they use cgo to build some C code, and cgo apparently always calls gcc, even on Windows, with the only solution being to install MinGW and make sure gcc.exe is available in the PATH. I guess once someone has gcc.exe available in Windows it becomes possible to go much further in the build process. Is my analysis correct, or can someone use clang-llvm, or even MSVC as the compiler on Windows for cgo?

[lsm5]

@awakecoding couple of questions:

1. Is this something that can't be handled by a linux binary + WSL2 (just thinking out loud, no idea myself)

2. Would you like to own this issue?

[xphyr]

I just took a look at this, and it looks like you can build a windows binary leveraging the make file.

I am using a OSX box to test, but if you run make local-cross you will end up with a compiled binary for OSX, linux.arm and windows.

You can also run make bin/skopeo.windows.amd64.exe and get just a windows binary.

There are caveats to the Windows binary (things like btrfs support are not available for obvious reasons).

[awakecoding]

@lsm5 @xphyr this isn't the first Go project where it appears difficult to get the thing built on Windows. If it's possible to cross-compile it, maybe add a prebuilt binary so people can start experimenting with it? It would still be quite useful to be able to build on Windows, without cross-compiling.

I don't have much time to spend on this, I was curious to try it out on Windows, and there was no binary around so I thought I may try building it. I got a little bit further, but I'm running into other issues now. I'll leave my notes if someone wants to give it a shot:

Install mingw-w64 and gpg4win:

choco install mingw
choco install gpg4win

Copy and rename the prebuilt gpg4win files alongside skopeo:

cd skopeo\cmd\skopeo
$GPG_DIR = "${Env:ProgramFiles(x86)}\GnuPG"
Copy-Item "$GPG_DIR\include" . -Recurse -Force
Copy-Item "$GPG_DIR\lib" . -Recurse -Force
Copy-Item "$GPG_DIR\bin\*.dll" ".\lib"
Get-ChildItem ".\lib\*.imp" | Rename-Item -NewName { $_.Name -Replace '.imp','.lib' }

gpg4win is unfortunately prebuilt for 32-bit Windows, and building it from source looks very painful. I would rather use the 64-bit version if someone has it. Anyway, you can set the environment variables to attempt building it:

$Env:GOARCH="386"
$env:GOOS="windows"
$Env:CGO_CFLAGS="-m32 -I$PWD\include"
$Env:CGO_LDFLAGS="-L$PWD\lib" 

The include files and the libraries will be found for gpgme, but then it fails later on:

# github.com/containers/image/v5/signature
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:16:16: undefined: gpgme.Context
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:66:44: undefined: gpgme.Context
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:67:14: undefined: gpgme.New
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:71:27: undefined: gpgme.ProtocolOpenPGP
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:75:28: undefined: gpgme.ProtocolOpenPGP
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:97:20: undefined: gpgme.NewDataBytes
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:126:20: undefined: gpgme.NewDataBytes
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:131:18: undefined: gpgme.NewDataWriter
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:135:25: undefined: gpgme.Key
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:135:61: undefined: gpgme.SigModeNormal
C:\go\pkg\mod\github.com\containers\image\[email protected]\signature\mechanism_gpgme.go:135:61: too many errors

I used some tricks from this old issue: https://github.com/proglottis/gpgme/issues/14

Maybe someone can go further than I did. If we could just have a proper build procedure for all the cgo packages on Windows, it could unblock native compilation for a lot of projects. From what I've seen, gpgme and a couple of packages used in skopeo are also used in many other projects like podman, etc.