Open sergeevabc opened 5 months ago
I tried to reproduce this in a Windows 7 VM but neither the 2.0 or 2.1 version seems to run for me. Could you try this new build? I appreciate the help.
windows.zip
Does not work, alas. You have optimized the binary between 2.0 and 2.1 (from 9.71 MB to 1+ MB), perhaps something valuable was lost along the way.
Yeah I did two things that dramatically cut the size:
I've already seen in other situations where UPX strips too much info and renders the binary unusable.
Here's a build with no UPX.
Here's a build with no UPX
Alas, it does not work here as well.
Well, that surely leaves the debug symbol stripping as the culprit. Either way, more binaries to try:
Either way, more binaries to try
Alas, nothing so far.
I compiled it myself using Go 1.21.4.
$ go.exe install github.com/braheezy/goqoa@latest
go: downloading github.com/braheezy/goqoa v1.1.0
go: downloading github.com/ebitengine/oto/v3 v3.0.0
go: downloading github.com/go-audio/audio v1.0.0
go: downloading github.com/go-audio/wav v1.1.0
go: downloading github.com/jfreymuth/oggvorbis v1.0.5
go: downloading github.com/spf13/cobra v1.7.0
go: downloading golang.org/x/sys v0.10.0
go: downloading github.com/jfreymuth/vorbis v1.0.2
go: downloading github.com/go-audio/riff v1.0.0
go: downloading github.com/inconshreveable/mousetrap v1.1.0
go: downloading github.com/spf13/pflag v1.0.5
$ goqoa.exe
Usage: goqoa [command]
Use 'goqoa help' for a list of commands.
Output: goqoa.zip
Installing from source will be the best route for platforms like Windows 7. The README has those instructions so this feels closed to me.
Installation from source significantly limits the potential of the program (and hence the spread of QOA format as such), because this method is in demand only among tech-savvy people. You could ask Github to build a separate, legacy version for Windows 7, using Go ≤ 1.21.4, like @schollz did with Croc.
I hear ya. I definitely want to make it easy as possible for people to try this format out!
I did another build with Go 1.21.4, which is slightly older minor version than I've been using so maybe it will help.
I reviewed the linked repository and the only real difference I could distinguish between our build processes is I build natively on a Windows machine and croc
builds on an Ubuntu machine but cross-compiles, hence the use of GOOS=windows GOARCH=amd64
. Note those are the same flags used when making a Windows 10 binary. The Go build tools don't distinguish between Windows 7 or 10.
It seems odd that cross-compiling could beat native compilation in terms of compatibility...but IIRC, the original reasons I went with the native compilation are no longer relevant. I might explore a larger refactor of the pipeline.
https://github.com/braheezy/goqoa/releases/tag/v2.0.0
$ goqoa.exe Usage: goqoa [command] Use 'goqoa help' for a list of commands.
https://github.com/braheezy/goqoa/releases/tag/v2.1.0
$ goqoa.exe