概要
題名通り、ある日 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のクロスコンパイルについて調べたり遊んだりしていて1、
go env -w GOOS=linux GOARCH=arm64
を実行したまま後始末していなかったのが原因でした2。
Goはビルド時の想定OSやgo install
のインストール先など諸々の環境依存の設定を環境変数で管理しており、go env -w
はその環境変数を編集するためのコマンドです3。
中でも GOOS
と GOARCH
は、go build
時にどのOS・どのアーキテクチャ向けにビルドするかを指定する変数になります。デフォルトでは、Goをインストールした環境に合わせた値になっています。
しかし、今回は上記のコマンドで GOOS=linux GOARCH=arm64
を設定してしまったので、私のコンピュータのOS(Windows)およびアーキテクチャとの乖離が生じてしまいました。これにより、 go build
などでビルドされたバイナリは、私のコンピュータ上ではうまく実行できなくなります。
たとえテストでも実行にはコンパイルが必要なので、 go test
も内側ではビルドを行っています4。その際の生成物もやはりLinux&ARM64用のものとなっているので、私の環境では動作しません。そのため、上記の %1 is not a valid Win32 application
エラーが発生したのです。しょーもな。
対処: 設定を元に戻す
Go環境変数を元に戻す場合、 go env -u [環境変数名]
コマンドを用います。
今回の場合なら、
go env -u GOOS GOARCH
です。これを実行したあとに再度 go test
を行ったところ、無事テストが実行されました5。めでたしめでたし。
-
当時主に参考にした記事は「Go開発環境のバラつきと対策」です。 ↩
-
原因特定に当たっては go - Running unit test in golang error: %1 is not a valid win32 application | Stack Overflow にお世話になりました。 ↩
-
余談ですが、大規模なソフトウェアで
go test
の実行が時々やたら遅くなるのは、このコンパイルによる部分が大きいようです。そのため、2回目以降の実行は速くなります。 ↩ -
テスト自体は失敗でしたが。 ↩