26-Apr-2022
［オクトラおぼえがき］

久しくまとめるのを忘れているととんでもないことになるので、重い腰を上げてまとめることに。

★5
ニコラ(短剣), トレサ(槍), ドロテア(槍), リュミス(斧), グロッサム(扇), ヴァルカン(本), アデル(短剣), イデア(剣), ガートルード(斧), プロメ(杖), オデット(本), ユーニィ(弓), リオナ(杖), オルベリク(剣), イェンロン(杖), ウ・ルダイ(槍), ティティ(扇), ニーナラーナ(杖), ラルゴ(槍), クロエ(弓), ノーニャ(槍), エレオノーラ(扇), A2(短剣), リシャール(剣), アラウネ(本), クラウザー(槍), タイタス(剣), ヘルミニア(弓), アーギュスト(短剣)

正直言って、管理できていません。追憶の旅人シリーズは手を出さないことに決めていたのですが、流石にタイタス・ヘルミニア・アーギュストを出されてしまうと…

今更気付いたのですが、ザンターの属性が間違っていました（風になっていましたが実際は光です）。また、アニエスは風属性だけでなく光属性も扱えたり、NieR:Automataコラボの9S/2Bも複数属性持ちだったりするので（逆にA2は属性無し）、属性別のカウント方法については考え直さないといけない感じです…という訳で、今回は省略。

上のリストには入れていませんが、ヘイズ(斧)が★4.5で来ています。クラスアップ用のアイテムは例によって銀導石の欠片を30000個頑張って集めることになるので、現時点では後回しです。56.3kg(22:20)

25-Apr-2022
［PCケースのリフォーム］

マシンの入れ替えが思っているほどうまく進んでいません。だったら前から気になっていた部分を直してしまおうということで、ケースの改造をやっていました。

安かったからという理由で22-Nov-2011にAZZA CSAZ-301(Toledo 301)を買っていますが、ゲーム仕様であるが故に青色LEDが妙にまぶしいとか（不要な結線をしないことで対応しています）、通気性をより良くするために天板に通気口が開いてでこぼこという、ちょっと使いにくいところがあります。

天板に付いたUSB端子の接触が悪くなってきて調子が悪いので、交換用の部品がAliExpressに転がっていないかなーと思って探してみたのですが…見つけられなかったので、でこぼこな天板＋各種端子をすぱっと取り払って平らな天板を付けてみることにしました。通気性が多少悪くなるとはいえ、爆熱なCPUやGPUを入れている訳ではありませんし、他の箇所も穴だらけなので多少塞がったくらいでは問題にはならないと考えています。

timg_20220420_213347_4.jpg timg_20220424_142220_6.jpg timg_20220424_142234_2.jpg timg_20220424_142252_6.jpg

板の色とケースの色が全然合っていませんが、OBS合版に押された「JAS1級 構造用パネル 30.0mm」のスタンプを活かしたいので敢えてこうしています。元の天板を取り払ったことで失われてしまうオーディオ端子とUSB端子、電源/リセットスイッチとLED類については、代替手段のある端子類はともかく、スイッチ/LEDはWiFiアンテナ用の穴が2つ開いたバックプレートにこれらを取り付けて対応することにしました。届いたバックプレートはamazon.co.jpで発注した際に表示される写真と若干異っていますが、まあ良いでしょう。

timg_20220419_210229_4.jpg timg_20220424_102832_2.jpg timg_20220424_125424_1.jpg timg_20220424_125456_7.jpg

LEDはサトーパーツ DB-9-T-CHY、押しボタンスイッチはELPA HK-PSS02H、急ぎで欲しかったのでちょっとお高いお値段になってしまいましたが…この程度の工作であれば、安く仕上げようと思えば安くできると思います。板金工作を厭わなければ、普通のバックプレートに穴を開ければ良い訳ですし。

当初は電源スイッチとHDDのLEDのみで済まそうと考えていたのですが、電源についてもLEDで状態が表示できる方が良いだろうということで、結局穴を一つ開けることになりました。WiFiアンテナ用の穴は、スイッチを取り付けるには小さく、LEDを付けるにはちょっと大きい（位置が悪いと僅かに隙間ができる）感じです。

PCの置き場の都合によりマシン前面よりも背面の方がアクセスが良かったりするため、バックプレートに取り付けた電源スイッチ/LEDは非常に便利です。部品があればもう一台のPCもこれに変えたいところですが…56.0kg(22:25)

24-Apr-2022
［OpenBSD-7.1へアップグレードしたは良いのですが］

JWMが2.3.7→2.4.1へ上がってしまったおかげでウィンドウシェード周りの操作が全然変わってしまい（設定次第で直せるような気もするのですが方法が分かりません）、非常に困ったのでWindowMakerへ移ることにしました。素直にxfce4を入れれば良いのかもしれませんが、xfce4-terminal等の取り巻きもあれこれインストールされるのが嫌だったというのが理由です。結局、JWMは半年くらいしか使わなかった、ということになります。

デフォルトのままだと使いにくいので、Window Maker Preferencesで以下の部分を変更しています。

Window Focus Preferences
Input Focus Mode: Autoを設定し、Automatically focus new windowsとRaise window when switching focus with keyboardにチェック
Window Handling Preferences
Opaque Move/Resize: 両方とも有効に
Menu Preferences
Always open submenus inside the screen, instead of scrolling.にチェック
Icon Preferences
Iconification Animation: None（後述のAnimationsが無効になっていればここで何を設定しても無効化されるが）
Other Configurations
AnimationsとSuperfluousは×を付けて無効化
Mouse Preferences
Double-Click Delay: 500ms

あとはMenu Preferencesで自分好みにメニューを構築して、fbpanelを取り払うことでなくなってしまう時計をwmclockで補います。システムトレイはdockerを使うのですが、portsに入っていないのでちょっと厄介です。WindowMaker自体は今でもメンテナンスされているものの、dockappsが結構古いままだったりするのが懸念材料です。

03-Apr-2022のマシン入れ替え、Windows10機として期待していたi5-4690+H81MHV3がメモリを選ぶのか手元のDDR3メモリでは何を使ってもmemtest86+で必ずエラーが出てしまうという事態により、Windows10機はCPUをAthlon X4 845→A8-7600に交換してこのまま使うことにしました。余った部品で一台組もうとすると大火傷しますね…（このパターン、結構やっている気がします）。

マシンの入れ替えついでに、PCケースのリフォームをやっていたのですが、これについては後日。56.7kg(15:15)

25-Apr-2022補足：Window Focus PreferencesにAutomatically focus new windowsの設定を追加。

29-Apr-2022補足：Window Focus PreferencesにRaise window when switching focus with keyboardと、Window Handling PreferencesのOpaque Move/Resizeの設定を追加。dockerはwmdockerとしてports化しました。

17-Apr-2022
［OpenBSDではよくある話。(6)］

10-Apr-2022の補足で書こうと思ったのですが、ちょっと分量があるのと、調べながら日記を書いているので別記事に。

16-Apr-2022のvmxscreenが動かない件、どうもdriver/etc/makerulesのLDFLAGS2に-rがあることでspecsの内容が正しく反映されなくなるのか、crt0.oの類がリンクできていないようです。得られたvmxscreenをobjdump/readelfで見るに、_start, _init, _finiのエントリがありません。

specsのstartfileの部分を読みやすく直すと、こうなるでしょうか。

      
%{!shared:
    crt0.o%s
    %{!r:
        %{static:
            crt1f.o%s
        }
        %{!static:
            crt1s.o%s
        }
    }
}
crti.o%s
%{!r:
    %{!static:
        %{!shared:
            solib.o%s
        }
    }
    crtbegin.o%s
}

crt0.oに対応する部分(jmp _C_startup)が見当たらないということは、-sharedが有効になっているとみなされているようです。crti.oに対応する部分が見当たらないことについては分からないのですが、-rの指定は有効となっているのかsolib.o, crtbegin.oはリンクされていないようです。

$(BD)/lib/i386e2/{crt0.o,crti.o}をリンクしてしまえば解決するように見えるのですが、driver/etc/makerulesをいじってみてもこんな結果になってしまいます。

という訳で、crt0.oとcrti.oの両方に対応するcrt0i.oを$(BD)/lib/i386e2に配置し（ソース）、makerulesを修正することで、vmxscreenは動くようになりました。

ドライバの場合、gmake mode=debugでデバッグモードのビルドを行ったバイナリや、printf()/bms_printf()を使ったコードのバイナリをkerextでロードしようとするとエラーが出るという問題があります。これは結構不便なのですが、詳細に調べている時間が無いのでとりあえず現状のままでぶん投げます。後者は<bsys/bms.h>にある、_PutString()が使えればそれを使って回避する手もあります。

なんか随分トラブルが多い気がしますが、clangでgccをビルドする際に結構warningを見かけているので、gccのビルドがうまくできていない可能性もあるのかもしれません。Linux上で開発環境を構築すればちゃんと動くのでしょうか…？57.2kg(15:05)

21-Apr-2022補足：Linux(Debian 11.3/amd64)上でも同様に開発環境を構築してみましたが、状況は変わりません。上記のcrt0回りの問題があり、makerules他の修正が必要です。

24-Apr-2022補足：binutilsの問題かと思い、以前のbinutils-2.28.1に替えて試してみましたが、状況は変わりません。gcc側の問題かもしれません。

28-Apr-2022補足：binutils-2.34のままgcc-9.4.0をgcc-8.5.0に替えたところ、driver/etc/makerulesをいじらずに（crt0.o, crti.oを使って）動作するvmxscreenが得られているのでgccの問題と言って差し支えなさそうです。とはいえ、bms_printf()を使ったコードのバイナリをkerextするとエラーになる問題はあるのですが。

29-Apr-2022補足：gcc-10.3.0で試してみましたが、$(BD)/include/btron/taskcomm.h等の#ifdef DEFINE_IFLIB〜#endifの中身を見てしまうのか、extended character ? is not valid at the start of an identifierといったエラーが出てしまいます。ソースコードの文字エンコーディングをgccに伝える必要があるのか、該当する部分を削除する必要があるのか、何かしらの手段で回避できそうな気もしますが…現時点においては、gccの挿げ替えは無改造ならgcc-8.x、多少手を入れるとしてもgcc-9.x辺りまでに留めておいた方が良いのではないかと考えています。

30-Apr-2022補足：$(BD)/tool/gnu/i386-unknown-elf/bin/gcc386に-finput-charset=eucjpをこんな感じに突っ込むことで文字コードの問題を回避できそうですが、全てのソースコードをEUC-JPで書かないといけなくなるのでこれはこれで厄介そうです。あと、gccの-rオプションによるcrt0周りの問題については、gcc-9を使ったときと同じ対策が必要です。

16-Apr-2022
［そういえば］

FTPではない手段で、ちょっとしたファイルの転送をTCP/IP越しにやらないといけないな…という訳でUNIX向けと超漢字向けにコードを書いていたのですが、何故こんなの作る必要があるんだっけ？と考えていたら18-May-2021（VMWare Playerの超漢字なディスクイメージをQEMUに食わせる）絡みの問題でした。

超漢字のファイル変換小物はともかく、開発用コンソールにあるftpクライアント(fget)はパッシブモードに対応していないので、仮想マシンをNATの向こう側に置いてしまうとファイルを取りに行けなくなります。仮想マシン用にネットワークのブリッジをちゃんと設定して、実マシンと同列にネットワークへ参加させれば問題はないのですが…QEMUでそれを設定するのは結構面倒なのでサボっていたらこういう問題にぶち当たったという訳です。

超漢字向けのものは10-Apr-2022でgcc-9.4.0化した超漢字開発環境でビルドしてみましたが、問題なく動いています。しかし、vmxscreenが全然動かなくなっています。gcc-4.2.4の時は.textに*(.rodata.*)を、gcc-5.5.0の時は更に*(.text.*)を$(BD)/lib/i386e2/reloc.lnkに追加する必要があったので、おそらく今回も何かをしないといけないのだと思いますが…現時点では見当がつきません。

VMWare Playerの超漢字なディスクイメージをQEMUに食わせて-serial stdioで標準入出力をシリアルコンソールとし、上記の理由でfgetが使えない状況に対応するには、socket()を使ったプログラムを書く練習をする必要があったというのが今日の日記です。57.0kg(22:10)

10-Apr-2022
［OpenBSDではよくある話。(5)］

csky-abiv2-elf向けのbinutils-2.34, gcc-9.4.0, newlib-4.1.0を08-Dec-2021にclangで構築したので、i386-elf, x86_64-elf向けの環境をこれに合わせることにしました。手順は06-Oct-2018のコピペ。

・x86_64-elf

binutils-2.34
../configure --target=x86_64-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-9.4.0 + newlib-4.1.0
../configure --target=x86_64-elf --enable-languages=c,c++ --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto --with-abi=m64

・i386-elf

binutils-2.34
../configure --target=i386-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-9.4.0 + newlib-4.1.0
../configure --target=i386-elf --enable-languages=c,c++ --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto

構築できているようなので、当分はこのままで良いかなあ…とも思っていた超漢字開発環境のアップデートを試しました。基本的には05-Nov-2018のgcc-5.5.0の時の手順と同じですが、今回は--disable-sharedを外しています。

binutils-2.34
../configure --prefix=/usr/local/brightv/tool/gnu --target=i386-unknown-elf --disable-nls --disable-werror
gcc-9.4.0
../configure --prefix=/usr/local/brightv/tool/gnu --target=i386-unknown-elf --enable-languages=c,c++ --with-newlib --disable-nls --disable-libssp --disable-libgomp --disable-lto --with-gmp=/usr/local
$(BD)/tool/gnu/lib/gcc/i386-unknown-elf/9.4.0/{demand.lnk,shared.lnk,crt0.o,crti.o,crtn.o,crt1f.o,crt1s.o,solib.o}
28-Oct-2009のReadMeと同様
$(BD)/tool/gnu/lib/gcc/i386-unknown-elf/specs
05-Oct-2014と同様
$(BD)/tool/gnu/i386-unknown-elf/bin/gcc386
05-Nov-2018と同様
$(BD)/lib/i386e2/reloc.lnk
05-Nov-2018と同様

$(BD)/applにあるソースコードのビルドでは、データボックスの処理にcppを使います。これはgcc由来のcppを使う必要があり、（OpenBSDでは$(BD)/etc/makerulesを修正して/usr/libexec/cppを呼び出しているため）clang由来のcppではエラーになります。makerulesに手を入れて、$(GNU_BD)/bin/i386-unknown-elf-cppを使うように修正してください。

ある程度のソースコードでビルドはできるようですが、今となっては認められない記法を使っているとエラーになります（たとえばappl/sample2/src/fileio.cのch = *((TC*)buf)++;）。バイナリが動作するかどうかは未確認なので、これは今後調べないといけませんね…56.4kg(04:55)

03-Apr-2022
［マシンの組み換えと仮想マシンの整理と(3)］

05-May-2021の続きなんですが、文章にまとめるだけの気力もないので箇条書き。

24-Apr-2019に入手したKLLISREのDDR3-1866な8Gのメモリ、その後4GB物も2枚買ってはみたのですが…8G/4GともにDDR3-1333の次はDDR3-1778（って何？）になっていたり、4GB物×2枚と昔使っていたADATAのDDR3-1600(XMP)な4GB×2枚とを混在させたら8GBしか認識されなかったりと、ちょっとイケてない感じです。下手にDDR3-1866と欲を出すのではなく、DDR3-1600なら良かったのかなーと後悔する部分もあるのですが、仕方ありません。

Windows10をAMD→Intelで動かすことにしたのは、AMDではWindows11でないとNested Hyper-Vを使えないという理由によるものです。仮想化環境を構築することを前提とすると未だにAMDよりはIntelの方が安心という状況に見えるのですが、これは今後改善されていくのでしょうか？56.1kg(22:45)