2026/02/22(日) [n年前の日記]
#1 [golang] 非MSYS2環境でFyneを使おうとして失敗
Windows11 x64 25H2 + Go 1.25.7 64bit で、GUIアプリを作成できるライブラリの Fyne を使おうとしたのだけど…。
_fyne-io/fyne: Cross platform GUI toolkit in Go inspired by Material Design
ビルドには gcc が必要になるらしいのでそのあたり試してたのだけどちょっと失敗。
結論を先に書く。MSYS2 UCRT64 の gcc を使うか、WinLibs の gcc を導入すればいい。
_fyne-io/fyne: Cross platform GUI toolkit in Go inspired by Material Design
ビルドには gcc が必要になるらしいのでそのあたり試してたのだけどちょっと失敗。
結論を先に書く。MSYS2 UCRT64 の gcc を使うか、WinLibs の gcc を導入すればいい。
◎ w64devkitを使おうとして失敗 :
w64devkit なるものを導入すれば gcc が使えるようになると知ったので試用してみた。
_skeeto/w64devkit: Portable C and C++ Development Kit for x64 (and x86) Windows
w64devkit-x64-2.5.0.7z.exe を入手して実行すると展開場所を尋ねられる。任意の場所に展開。bin/ にPATHを通して利用する。
しかし、fyne_demo をビルドしようとしたら、エラーが出てしまう。
ググったところ、w64devkit の gcc は BigObj なる形式のオブジェクトファイルを出力するようで、これが Go言語の cgo ―― Go言語からC言語の関数やライブラリを呼び出すための仕組みと相性が悪いというか、Go言語側が BigObj を扱えないらしい。
_debug/pe: big-obj is not supported - Issue #24341 - golang/go
_cmd/cgo: `cannot parse _cgo_.o as ELF, Mach-O, PE or XCOFF` on Windows - Issue #62236 - golang/go
_Cgo: cannot parse gcc output - Getting Help - Go Forum
_error when compiling a Go program with cgo on a 64-bit Windows 7 (v6.1 SP1) system - Issue #290 - skeeto/w64devkit
これじゃ使えないな…。w64devkit をインストールしておく意味はない…。展開場所をまるっと削除してアンインストールしておいた。
_skeeto/w64devkit: Portable C and C++ Development Kit for x64 (and x86) Windows
w64devkit-x64-2.5.0.7z.exe を入手して実行すると展開場所を尋ねられる。任意の場所に展開。bin/ にPATHを通して利用する。
しかし、fyne_demo をビルドしようとしたら、エラーが出てしまう。
> go install fyne.io/fyne/v2/cmd/fyne_demo@latest go: downloading fyne.io/fyne/v2 v2.7.3 go: downloading fyne.io/fyne v1.4.3 go: downloading github.com/go-text/typesetting v0.3.3 go: downloading github.com/yuin/goldmark v1.7.8 go: downloading golang.org/x/image v0.24.0 go: downloading golang.org/x/sys v0.30.0 go: downloading fyne.io/systray v1.12.0 go: downloading github.com/fyne-io/image v0.1.1 go: downloading github.com/go-gl/glfw/v3.3/glfw v0.0.0-20240506104042-037f3cc74f2a go: downloading github.com/fredbi/uri v1.1.1 go: downloading github.com/jeandeaual/go-locale v0.0.0-20250612000132-0ef82f21eade go: downloading github.com/nicksnyder/go-i18n/v2 v2.5.1 go: downloading golang.org/x/text v0.22.0 go: downloading github.com/fyne-io/oksvg v0.2.0 go: downloading github.com/srwiley/rasterx v0.0.0-20220730225603-2ab79fcdd4ef go: downloading github.com/go-text/render v0.2.0 go: downloading github.com/go-gl/gl v0.0.0-20231021071112-07e5d0ea2e71 go: downloading github.com/godbus/dbus/v5 v5.1.0 go: downloading github.com/jsummers/gobmp v0.0.0-20230614200233-a9de23ed2e25 go: downloading golang.org/x/net v0.35.0 go: downloading github.com/srwiley/oksvg v0.0.0-20221011165216-be6e8873101c go: downloading github.com/davecgh/go-spew v1.1.1 go: downloading github.com/pmezard/go-difflib v1.0.0 # github.com/go-gl/gl/v2.1/gl cgo: cannot parse gcc output $WORK\b311\\_cgo_.o as ELF, Mach-O, PE, XCOFF object # github.com/go-gl/glfw/v3.3/glfw cgo: cannot parse gcc output $WORK\b320\\_cgo_.o as ELF, Mach-O, PE, XCOFF object
ググったところ、w64devkit の gcc は BigObj なる形式のオブジェクトファイルを出力するようで、これが Go言語の cgo ―― Go言語からC言語の関数やライブラリを呼び出すための仕組みと相性が悪いというか、Go言語側が BigObj を扱えないらしい。
_debug/pe: big-obj is not supported - Issue #24341 - golang/go
_cmd/cgo: `cannot parse _cgo_.o as ELF, Mach-O, PE or XCOFF` on Windows - Issue #62236 - golang/go
_Cgo: cannot parse gcc output - Getting Help - Go Forum
_error when compiling a Go program with cgo on a 64-bit Windows 7 (v6.1 SP1) system - Issue #290 - skeeto/w64devkit
これじゃ使えないな…。w64devkit をインストールしておく意味はない…。展開場所をまるっと削除してアンインストールしておいた。
◎ MSYS2上でビルド :
MSYS2 UCRT64上で golang をインストールして fyne_demo をビルドしてみた。その環境ならビルドも通って、動作もした。
pacman -S mingw-w64-ucrt-x86_64-go pacman -S mingw-w64-ucrt-x86_64-toolchain go install fyne.io/fyne/v2/cmd/fyne_demo@latest fyne_demo
◎ WinLibs版でビルド :
WinLibs なるものを導入することでも gcc が使えるらしい。zipを解凍して、PATHを通すだけで使える。
_WinLibs - GCC+MinGW-w64 compiler for Windows
_C言語 | MinGW-w64(WinLibs版)のダウンロードとインストール
winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-13.0.0-r5.zip を入手して任意の場所に解凍。今回は D:\Dev\winlibs\ucrt\mingw64\ に置いた。
bin/ にPATHを通せばgccが使えるようになるけれど、今回は winlibs_enable.bat というbatファイルを作成して、このbatファイルを実行すればPATHが通るようにしておいた。
winlibs_enable.bat
この WinLibs版のgccを使ったら、fyne_demo をビルドすることができた。
_WinLibs - GCC+MinGW-w64 compiler for Windows
_C言語 | MinGW-w64(WinLibs版)のダウンロードとインストール
winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-13.0.0-r5.zip を入手して任意の場所に解凍。今回は D:\Dev\winlibs\ucrt\mingw64\ に置いた。
bin/ にPATHを通せばgccが使えるようになるけれど、今回は winlibs_enable.bat というbatファイルを作成して、このbatファイルを実行すればPATHが通るようにしておいた。
winlibs_enable.bat
@echo off set WINLIBSPATH=D:\Dev\winlibs\ucrt\mingw64\bin set PATH=%WINLIBSPATH%;%PATH% echo WinLibs (ucrt) enabled. [%WINLIBSPATH%]
この WinLibs版のgccを使ったら、fyne_demo をビルドすることができた。
go install fyne.io/fyne/v2/cmd/fyne_demo@latest fyne_demo
◎ 依存しているDLLを調べたい :
生成したexeは、どんなDLLに依存しているのか気になった。例えば MSYS2 UCRT64上の Go でビルドして作ったexeは、MSYS2 の何か(DLL)が必要だったりしないか。そうなると、他のPCに持っていって動作させるのが面倒になる。
依存してるDLLを調べないといけない。
MSYS2上であれば、ldd が使える。
Windows上でネイティブ(?)に使えるツールは無いものだろうか…。
Dependencies というツールが使えるらしい。
_lucasg/Dependencies: A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.
_覚書 : Dependency Walkerはもう古い! Windows 10ならDependenciesを使え! | FRONTL1NE Community
_windows 10 では dependency walker じゃなくて dependencies を使う - いろいろ備忘録日記
_Windows10以降で.exeや.dllの依存関係を調べる方法( Dependencies ) - 放浪猫
_Dependencies: 対象DLLの変化を即座に反映する (バイナリキャッシュを無効にする方法)
Dependencies_x64_Release.zip を入手して解凍。今回は D:\Dev\Dependencies\Dependencies_x64_Release\ に置いておいた。中に入っている DependenciesGui.exe を実行すると起動する。
ウインドウに .exe をドラッグアンドドロップすれば、依存しているDLLの一覧が表示される。
とりあえず、今回ビルドした Fyne を使ってるexeは、MSYS2 関係のDLLを参照しないで、Windows11に入ってるDLLだけを参照しているように見えた。たぶんこれなら大丈夫そうかな…。
依存してるDLLを調べないといけない。
MSYS2上であれば、ldd が使える。
ldd ./hoge.exe
Windows上でネイティブ(?)に使えるツールは無いものだろうか…。
Dependencies というツールが使えるらしい。
_lucasg/Dependencies: A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.
_覚書 : Dependency Walkerはもう古い! Windows 10ならDependenciesを使え! | FRONTL1NE Community
_windows 10 では dependency walker じゃなくて dependencies を使う - いろいろ備忘録日記
_Windows10以降で.exeや.dllの依存関係を調べる方法( Dependencies ) - 放浪猫
_Dependencies: 対象DLLの変化を即座に反映する (バイナリキャッシュを無効にする方法)
Dependencies_x64_Release.zip を入手して解凍。今回は D:\Dev\Dependencies\Dependencies_x64_Release\ に置いておいた。中に入っている DependenciesGui.exe を実行すると起動する。
ウインドウに .exe をドラッグアンドドロップすれば、依存しているDLLの一覧が表示される。
とりあえず、今回ビルドした Fyne を使ってるexeは、MSYS2 関係のDLLを参照しないで、Windows11に入ってるDLLだけを参照しているように見えた。たぶんこれなら大丈夫そうかな…。
[ ツッコむ ]
#2 [ruby] gem listからバージョン情報を除去したい
Ruby の gem を使ってインストールしたパッケージ一覧は gem list で得られる。
ただ、この一覧は、「パッケージ名 (バージョン番号)」という形で出力される。
バージョン情報を除去したい。
以前は Perl を使ってやってたけれど、Ruby でもできそうだよなと…。AI (Google Gemini)に尋ねてみたら色々な書き方を提示されて、「やり方は色々あるんだなあ…」と感心(?)したのでメモ。
パッケージ名とバージョン番号は空白文字で区切られているので、空白文字で分割して最初の要素だけ取り出すのが簡単ですよ、とAIが言っている。なるほどたしかにその通りかも。
gem list
ただ、この一覧は、「パッケージ名 (バージョン番号)」という形で出力される。
> gem list *** LOCAL GEMS *** abbrev (0.1.2) ast (2.4.3) atk (4.3.5) base64 (0.2.0) benchmark (default: 0.4.0) bigdecimal (3.1.8) bundler (default: 4.0.6) cairo (1.18.4) cairo-gobject (4.3.5) ...
バージョン情報を除去したい。
以前は Perl を使ってやってたけれど、Ruby でもできそうだよなと…。AI (Google Gemini)に尋ねてみたら色々な書き方を提示されて、「やり方は色々あるんだなあ…」と感心(?)したのでメモ。
gem list | perl -pe "s/ \(.*\)//"
gem list | ruby -pe '$_.sub!(/\s.*/, "")'
gem list | ruby -ane 'puts $F[0]'
gem list | ruby -ne 'puts $_.split(" ").first'
- -e : 実行するスクリプトの指定
- -p : 標準入力を1行ずつループで読み込んで特殊変数 $_ を出力。
- $_ : 1行分が入ってる特殊変数
- .sub! : 文字列置換。初めにマッチした部分のみ置換する。
- -n : 標準入力を1行ずつ読み込むループ。
- -a : 読み込んだ1行を自動的に分割。区切り文字はスペースやタブ文字。特殊変数 $F に入る。
- puts : 標準出力に出力。
- .split() : 区切り文字で分割。
- .first : 配列の最初の要素だけを返す。[0] と同じ。
パッケージ名とバージョン番号は空白文字で区切られているので、空白文字で分割して最初の要素だけ取り出すのが簡単ですよ、とAIが言っている。なるほどたしかにその通りかも。
[ ツッコむ ]
#3 [prog][golang] MSYS2上でパスを変換
Windows11 x64 25H2 + MSYS2 UCRT64上で、Goでビルドして作ったはずのツールが ―― task.exe が呼び出せなくて悩んでいた。~/.bashrc の中に以下を追加してあるのだけどなあ…。どうして呼び出せないのか…。
確認してみたら、GOPATH の中身が以下のようになっていた。
これはダメな気がする。最初の文字が C:\ から始まってるし、\ と / が混在してしまっている。MSYS2 上では、/c/Users/USERNAME/go/bin になっていないといけないのでは?
AI(Google Gemini)に、こういうのを変換できる何かはないのと尋ねてみたら、「cygpathというコマンドがあるよ」と言ってきた。
ほほう。これは良い。良いではないか。
~/.bashrc の中に以下を書いた。
これで、MSYS2上でも $GOPATH/bin が正しくPATHに追加される状態になった。
export PATH=$PATH:$GOPATH/bin
確認してみたら、GOPATH の中身が以下のようになっていた。
$ echo $(go env GOPATH)/bin C:\Users\USERNAME\go/bin
これはダメな気がする。最初の文字が C:\ から始まってるし、\ と / が混在してしまっている。MSYS2 上では、/c/Users/USERNAME/go/bin になっていないといけないのでは?
AI(Google Gemini)に、こういうのを変換できる何かはないのと尋ねてみたら、「cygpathというコマンドがあるよ」と言ってきた。
$ cygpath -u $(go env GOPATH)/bin /c/Users/USERNAME/go/bin
ほほう。これは良い。良いではないか。
~/.bashrc の中に以下を書いた。
export PATH="$PATH:$(cygpath -u $(go env GOPATH))/bin"
これで、MSYS2上でも $GOPATH/bin が正しくPATHに追加される状態になった。
[ ツッコむ ]
#4 [prog][zatta][neta] task.exeという命名はマズイ
思考メモ。
先日、Go言語製のタスクランナー task をインストールしたけれど。task という名前はマズイなと…。
MSYS2 の場合、Taskwarrior というTODO管理ツールのパッケージが存在していて、このパッケージが task.exe を提供しちゃっている…。
_Package: task - MSYS2 Packages
Go言語製タスクランナー task.exe と名前が衝突してしまう…。どうしてどいつもこいつも一般的な単語を使った安易な命名をしてしまうのか…。一体何度やらかせば気が済むのか…。でもまあ、そんなことを言い出したら、make なんて最悪のネーミング、という話にもなるのかな…。
少しググってみたら…。
taskに似ていて衝突しない名前は無いのかなとググってみたけど…。gtask, gotask, task555, taskmake, taske, taskete…。ダメだ。自分如きが思いつく文字列は全部使われてる。
この手のコマンドは打鍵数が極力少ないワードにしたいはずだし、そうなると衝突しない名前を見つけるのは難しそう。大体は使われちゃってるよなあ…。
先日、Go言語製のタスクランナー task をインストールしたけれど。task という名前はマズイなと…。
MSYS2 の場合、Taskwarrior というTODO管理ツールのパッケージが存在していて、このパッケージが task.exe を提供しちゃっている…。
_Package: task - MSYS2 Packages
Go言語製タスクランナー task.exe と名前が衝突してしまう…。どうしてどいつもこいつも一般的な単語を使った安易な命名をしてしまうのか…。一体何度やらかせば気が済むのか…。でもまあ、そんなことを言い出したら、make なんて最悪のネーミング、という話にもなるのかな…。
少しググってみたら…。
- Taskwarrior 1.2 がリリースされたのが2014年。
- go-task 1.0.0 がリリースされたのが2017年。
taskに似ていて衝突しない名前は無いのかなとググってみたけど…。gtask, gotask, task555, taskmake, taske, taskete…。ダメだ。自分如きが思いつく文字列は全部使われてる。
この手のコマンドは打鍵数が極力少ないワードにしたいはずだし、そうなると衝突しない名前を見つけるのは難しそう。大体は使われちゃってるよなあ…。
◎ 妄想 :
もしかすると、こういうのって非英語圏のワードを使って命名したほうがいいのかもしれないな…。ガイナックスのガイナとか、スタジオジブリのジブリとか、特定の地域でしか使われてないワードを当てるノリ。ジブリはちょっと違うか。ジブリだと思ってたらジブリじゃなかったらしいし。アレはわざと変えてみたのか、それとも偶然なのか、どっちなんだろう。
でも、非英語圏のワードを使うと呪文っぽくなりそうな気もする。いっそのこと呪文らしいワードにしたほうが良かったりして。プログラマーのウイザード感も出るし。
日本のアニメが好きな作者さんが「cano」「pample」「pimple」「pampopum」というコマンド名を命名するのもアリだろうか…。ググったら「cano.exe」はもうあった。しかもマルウェア…。
でも、非英語圏のワードを使うと呪文っぽくなりそうな気もする。いっそのこと呪文らしいワードにしたほうが良かったりして。プログラマーのウイザード感も出るし。
日本のアニメが好きな作者さんが「cano」「pample」「pimple」「pampopum」というコマンド名を命名するのもアリだろうか…。ググったら「cano.exe」はもうあった。しかもマルウェア…。
[ ツッコむ ]
#5 [golang] Chocolatey経由でgo-taskをインストール - 2026/02/22
MSYS2 UCRT64上で go-task がインストールできなくてアレコレしているうちに、Chocolatey 経由で go-task をインストールしてしまった。一応メモしておく。
管理者権限で PowerShell 7 を開いて以下を打った。
2ヶ所に入ってしまっているけれど…。まあいいか…。とりあえず現状では Chocolatey版が使われる。Go言語でインストールした版より、ほんのちょっとだけ古い模様。
管理者権限で PowerShell 7 を開いて以下を打った。
choco install go-task
> where task C:\ProgramData\chocolatey\bin\task.exe C:\Users\mieki256\go\bin\task.exe > task --version 3.46.4
2ヶ所に入ってしまっているけれど…。まあいいか…。とりあえず現状では Chocolatey版が使われる。Go言語でインストールした版より、ほんのちょっとだけ古い模様。
[ ツッコむ ]
以上、1 日分です。