概要

題名通り、ある日 go test を実行したら

fork/exec C:\Users\XXX\AppData\Local\Temp\go-build2550557918\b001\YYY.test: 
%1 is not a valid Win32 application.

とエラーが出て失敗するようになったので、その原因と解消方法を調べた結果をメモした記事です。

蓋を開けると非常にしょうもない＆滅多にない原因なので記事としての価値は微妙ですが、同じような事態に遭遇した方のために書き残しておきます。

原因: GOOS、GOARCHの設定がおかしかった

結論から言うと、上記エラーが出る前、Goのクロスコンパイルについて調べたり遊んだりしていて¹、

go env -w GOOS=linux GOARCH=arm64

を実行したまま後始末していなかったのが原因でした²。

Goはビルド時の想定OSやgo installのインストール先など諸々の環境依存の設定を環境変数で管理しており、go env -w はその環境変数を編集するためのコマンドです³。

中でも GOOS と GOARCH は、go build時にどのOS・どのアーキテクチャ向けにビルドするかを指定する変数になります。デフォルトでは、Goをインストールした環境に合わせた値になっています。

しかし、今回は上記のコマンドで GOOS=linux GOARCH=arm64 を設定してしまったので、私のコンピュータのOS(Windows)およびアーキテクチャとの乖離が生じてしまいました。これにより、 go build などでビルドされたバイナリは、私のコンピュータ上ではうまく実行できなくなります。

たとえテストでも実行にはコンパイルが必要なので、 go test も内側ではビルドを行っています⁴。その際の生成物もやはりLinux＆ARM64用のものとなっているので、私の環境では動作しません。そのため、上記の %1 is not a valid Win32 application エラーが発生したのです。しょーもな。

対処: 設定を元に戻す

Go環境変数を元に戻す場合、 go env -u [環境変数名] コマンドを用います。
今回の場合なら、

go env -u GOOS GOARCH

です。これを実行したあとに再度 go test を行ったところ、無事テストが実行されました⁵。めでたしめでたし。

当時主に参考にした記事は「Go開発環境のバラつきと対策」です。 ↩
原因特定に当たっては go - Running unit test in golang error: %1 is not a valid win32 application | Stack Overflow にお世話になりました。 ↩
go command - Print Go environment information ↩
余談ですが、大規模なソフトウェアで go test の実行が時々やたら遅くなるのは、このコンパイルによる部分が大きいようです。そのため、2回目以降の実行は速くなります。 ↩
テスト自体は失敗でしたが。 ↩