In general you only need to set env vars like GOOS and GOARCH if you are cross-compiling. That is, building a program for a different architecture. Don't set env vars unless you understand the purpose of the vars.
The compilation errors are because the code relies on a package that is incompatible with the Windows OS. What is interesting is a quick search of the issues for the project turns up https://github.com/ThomasHabets/cmdg/issues/118 which suggests that it did, at least in the past, support being built on Windows. But looking at the code now that is clearly no longer true (if it ever was). WSL is the "Windows Subsystem for Linux". Basically, running Linux side-by-side with Windows including sharing file systems and other resources. You should be able to build and run this program on WSL if you install the Go toolchain in WSL. You could, in theory, cross-compile the program on Windows to get a program that runs on Linux (and thus WSL) but I wouldn't recommend doing so for someone new to the Go ecosystem. On Sun, Apr 20, 2025 at 9:40 PM John O'Regan <john.a.ore...@gmail.com> wrote: > Hello All, > > I'm new to Golang and to the group so apologies in advance for any > stupid questions. Please don't flame me! :) > > I'm attempting to build Thomas Habets' cmdg on my Windows 10 machine. > This is as far as I get: > > - - - - > > >set "GOOS=windows" > > >set "GOARCH=386" > > >cd > C:\Users\User\cmdg > > >go build .\cmd\cmdg > # github.com/ThomasHabets/cmdg/pkg/input > pkg\input\input.go:129:52: undefined: unix.Timeval > pkg\input\input.go:134:14: undefined: unix.Timeval > pkg\input\input.go:172:14: undefined: unix.FdSet > pkg\input\input.go:173:25: undefined: unix.NFDBITS > pkg\input\input.go:181:17: undefined: unix.Select > pkg\input\input.go:181:42: undefined: unix.FdSet > pkg\input\input.go:397:33: undefined: syscall.SIGWINCH > > - - - - > > I consulted the Copilot Chatbot and this is its response: > > - - - - > > The errors you’re seeing— > undefined: unix.Timeval > undefined: unix.FdSet > undefined: unix.NFDBITS > undefined: unix.Select > —occur because the code in pkg/input/input.go uses the > golang.org/x/sys/unix package, which is only available on Unix-like > operating systems. Functions and types like Timeval, FdSet, NFDBITS, > and Select are specific to Unix systems and aren’t defined on Windows. > > Below are some approaches to resolving these errors: > > --- > > 1. Conditional Compilation with Build Tags > > If the functionality in that file isn’t required on Windows, you can > simply exclude it from Windows builds. At the top of your source file > (input.go), add a build constraint that tells Go to compile that file > only on Unix-like systems. For example: > > go > // +build linux darwin freebsd > > This way, when you build on Windows, this file will be skipped. You’ll > then need to decide what to do for Windows—either provide a stub > implementation or entirely remove the functionality for that build. > > --- > > 2. Implementing Windows Alternatives > > If the functionality is essential for your app on every platform, > you’ll have to provide Windows-specific code. Windows does have a > select function provided through its Winsock API, and there’s a > corresponding package > [golang.org/x/sys/windows](https://pkg.go.dev/golang.org/x/sys/windows) > <http://golang.org/x/sys/windows%5D(https://pkg.go.dev/golang.org/x/sys/windows)> > that exposes Windows system calls. However, note that: > > - Types and Structures : Windows doesn’t use Timeval and FdSet in the > same manner. You might need to map these calls to their Windows > counterparts or re-architect your logic for handling I/O multiplexing. > - API Differences : The Windows API for network/select operations can > differ in both usage and behavior. A direct replacement might not be > trivial. > > In this scenario, creating two separate source files is a common approach: > - Create an input_unix.go containing Unix-specific code with a build > tag like // +build !windows. > - Create an input_windows.go with Windows-specific implementations and > the build tag // +build windows. > > This method keeps your platform-specific code separate while keeping > the overall API of your module consistent. > > --- > > 3. Refactoring Your Code > > Examine what the Unix-specific code is trying to achieve. For example: > - If you’re using Select for non-blocking I/O or waiting on file > descriptors , determine if Windows has an equivalent method or if you > can use Go’s higher-level abstractions (like channels or the netpoll > package) to achieve the same behavior. > - For timing out operations or polling , consider whether you can use > Go’s built-in mechanisms (such as time.After) to achieve the desired > effect with cross-platform compatibility. > > --- > > Next Steps > > - Evaluate Necessity: Decide whether the Unix-specific functionality > is essential on Windows. If not, stub out or conditionally compile > that part of your code. > - Create Platform-Specific Files: Split your code into two files > (input_unix.go and input_windows.go) with proper build tags to handle > each platform's requirements separately. > - Consult Documentation: Look into > [golang.org/x/sys/windows](https://pkg.go.dev/golang.org/x/sys/windows) > <http://golang.org/x/sys/windows%5D(https://pkg.go.dev/golang.org/x/sys/windows)> > for Windows-specific system call equivalents and the nuances of how > Windows handles I/O and system-level operations. > > If you run into further specific issues while restructuring the code > or need guidance with Windows API equivalents, feel free to provide > more details, and I can help brainstorm a solution tailored to your > app's functionality. Happy coding! > > - - - - > > Sounds like good advice. Just one problem... I don't understand a > word of it. I'm in way over my head. > > Would I be better off installing WSL? Would cmdg run "out of the box" > under WSL? > > Any help appreciated. > > Thanks! > > John > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/CALwjjMirYsMr8FMvBz_7K6Vo_8FMGndw%2B_YCAU0gaNxoauu2LQ%40mail.gmail.com > . > -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_OsJwjwvDimFciEHN8VjJwG-K_g_y405r8c0iCZz480w%40mail.gmail.com.
