9月XX日：苦闘

WINEにはより詳細なログを取るためのWINEDEBUGという環境変数が用意されているものの，dxdiagがエラー終了するまでに30万行ほどのログを出力するのでとても調べきれない。また，エラーメッセージを手掛りにあれこれググってみても，似たような症状は出てこない。

そもそもWINEが全然動かないわけではなく，同じバイナリがVBox上では動いているのだから，問題はWINEではなく，実行環境側にありそうだ。

VBoxと実機の違いで最初に思いつくのはビデオカード回りで，エラーになる実機はGPU内蔵のRyzen5を積んでいる。それではIntelなCPUではどうだろう，と考えて，同じくGPU内蔵タイプのCore i3で試しても同じエラーで終了する。どうやらVBoxのビデオドライバのみが遅いながらも機能するらしい。

OpenGLが絡むし，機種ごとに違いがあるようなので，各ビデオカード用にDRIのライブラリを用意しているMesaあたりが原因だろうか…… とMesaのビルドオプションをあれこれイジってビルドし直してみても変化なし。MesaのドライバはLLVMを使っていたなぁ，，とLLVMに遡って再ビルドしても変化なし。MesaをイジればXのドライバも影響を受けるかも，とXのライブラリやドライバ類を再ビルドしてもダメ。いずれの修正も64ビット版，32ビット版それぞれに反映させなければならないので，ビルドの手間は2倍かかる。

MesaもWINEも更新頻度は高いので，しばらく悩んでいるうちに新しいバージョンがリリースされる。ほのかな期待を持って新バージョンを試してみても，やはりダメ。

1ヵ月近くあれこれ試しても解決できなかったので，当初の目的だったWINE対応は諦めて，CLFSレベルのMultilib環境ということでお茶を濁すかなぁ……，と考えがちになってきた。

9月XY日：光明

今回のトラブルが何故ここまで厄介なのかを考えると，WINEを動かすためには150を超える32ビット版のパッケージが必要で，たぶん，その中に問題を起しているパッケージがあるものの，150のパッケージは相互に関連していて，一部だけを切り分けて試すことができないからだ。

トラブル解決の基本は「条件を絞りこんで問題を切り分けること」なので，今回の場合，どうすれば問題を切り分けるだろうか，と考えていくうち，Plamo以外のディストリビューションのWINE用のパッケージを流用すれば何とかなるのでは，と思いついた。

そのためには，あるディストリビューションでWINEがちゃんと動き，WINEを動かすためにはどのようなパッケージが必要になるかを確認する必要がある。通常，他のディストリビューションの動作テストはVBox上でやるのだけど，今回はハードウェア環境も影響しているので実機上で試す必要がある。そこでまずハードディスクを整理して専用のパーティションを用意し，そこにUbuntuを入れてみた。

Ubuntu上で"sudo apt install wine64"を実行すると，多数のパッケージが芋ヅル式にインストールされていく。一通りインストールと設定が終って"wine dxdiag" を実行すると，フルスクリーン上でDirectXキューブが問題なく回転した。

それでは「UbuntuのWINE関連パッケージと手元でビルドしたパッケージの違いは……」と調べようとしたものの，UbuntuのようなDebian系のディストリビューションではパッケージの分け方がPlamoとは大きく異なるので簡単に比較できそうにない。

次に目を付けたのがArch Linuxで，こちらも同様にHDD上に入れた後，"pacman"を使ってWINEをインストールし，dxdiagも動作することを確認した。

Arch LinuxのパッケージはPlamoとよく似た作りになっていてtarコマンドだけで展開できる。そこで，Arch LinuxのWINE関連パッケージをPlamo環境に持ち込み，既存のファイルに上書きする形でインストールしてみたところ，Plamo環境でもdxdiagがきちんと実行できた。

Arch Linuxのバイナリを使えばPlamo上でもdxdiagが動作するなら，後はどのパッケージが原因でクラッシュするのかを調べる作業になる。そこで手元で作ったPlamo用のパッケージを一つずつ書き戻しながらdxdiagの動作を調べると，libglvndというライブラリの32ビット版をインストールするとクラッシュすることが判明した。

libglvndというライブラリは，WINE用のパッケージを作成している時に見つけたソフトウェアで，OpenGLのベンダー依存APIへの呼び出しを適切なライブラリへ振り分ける機能を提供しているらしい。

確かにlibglvndはMesaのビルド時にもチェックされるOpenGLの要（かなめ）のひとつではあるものの，小さなライブラリでビルド時に指定できるオプションもそれほど多くはない。一体何が違っているのだろう，とArch LinuxのPKGBUILDスクリプトを調べたところ，32ビット版のconfigure時に"--build=i686-unknown-linux-gnu"を渡している。一方，Plamoのビルドスクリプトでは"--host=x86-pc-linux"を指定していた。

そう言えば，libglvndは一部アセンブラのコードが入っているようで，"gcc -m32"だけではビルドできなかったから"--host=..."で機種を明示したのだっけ，と思い出し，改めて"--build=i686-unknown-linux-gnu"の指定でビルドし直すと，手元で作成したlibglvndでもdxdiagが正しく動作し，PlamoでもWINEが動作する，と言えるようになった。

改めて"--host=x86-pc-linux"と"--build=i686-unknown-linux-gnu"の指定で何が違ってくるのかを調べたところ，i686-unknown-linux-gnuの指定ではi686，すなわちx86系の第6世代CPUと認識し，それらが持っている拡張機能（MMX，3DNOW, SSE等）を使うようにビルドされるのに対し，x86-pc-linux-gnuの指定ではより汎用的なx86(=80386)と判断され，i686用にアセンブラで書かれた拡張機能が利用できなくなることが原因のようだ。

-- build/Makefile      2020-01-22 08:47:18.568112237 +0900
+++ build_ng/Makefile   2020-01-22 08:46:40.478973090 +0900
@@ -86,9 +86,9 @@ POST_INSTALL = :
 NORMAL_UNINSTALL = :
 PRE_UNINSTALL = :
 POST_UNINSTALL = :
-build_triplet = i686-pc-linux-gnu
-host_triplet = i686-pc-linux-gnu
-target_triplet = i686-pc-linux-gnu
+build_triplet = x86_64-pc-linux-gnu
+host_triplet = x86-pc-linux-gnu
+target_triplet = x86-pc-linux-gnu
...
-CFLAGS =  -Wall -Werror -include config.h -fvisibility=hidden  -DUSE_X86_ASM -DUSE_MMX_ASM
  -DUSE_3DNOW_ASM -DUSE_SSE_ASM
+CFLAGS =  -Wall -Werror -include config.h -fvisibility=hidden 
 CPP = gcc -m32 -E

ビルド時にi686とx86を間違えた1つのパッケージのせいでシステム全体が動かなくなる，ディストリビューションを作っているとこの手のトラブルにはちょくちょく遭遇するものの，今回はそれが150余のパッケージの中に紛れこんでいたため，検出にずいぶん時間がかかってしまった。

「急がば回れ」ではないけれど，面倒な仕事ほど，それぞれの作業に細心の注意が必要なことを肝に銘じることにしよう。

このシリーズで取りあげたWINEの作成過程で一番キツかったのが，今回取りあげたDirectXの動作不能問題です。

全体像が見えない中で32ビット版のライブラリを作り続けるのも大変でしたが，こちらはキリのいいところで実行するconfigureの結果で進捗がわかったので，少しずつでも目的地に近づいていることを感じられたのに対し，DirectXの動作不能問題は出口があるのかすらわからない迷宮の中を延々と手探りでさまよっているような絶望感に苛（さいな）まれる日々でした。

その分，出口らしい明りが見え，つまづきながらもそちらに辿りつき，脱出できた時の爽快感は，まさに「エウレカ!」と叫びたくなるものでした。筆者にとっては，この「エウレカ」体験で得られる爽快感が，ディストリビューションを作り続ける原動力になっているようです。

さて，ビルド時の苦労話が一段落したので，次回はWINEの設定や遊び方を紹介しましょう。