Jamano's Blog 2nd gen.
年末ぎりぎりのタイミングでVer.6が公開されました。私のメインフィールドであるFedoraはRawhideが6.0rc1で、本提供は5.12で止まっていますので、Windows版でテスト。
噂通り、そのままの状態で日本語が表示されます。なんとなくカナ部と漢字部の幅の割当が間違っている気がしないでも無いのですが、例の大騒ぎをしなくても良いのは助かります。まだソースは見ていないのですが、newstoke_fontを入れ替えれば解決するのかな?
Fedora側の-o3処理祭りがようやく7割方終わったところなので、片付いたら試してみますか。
その前に現在SSDをつなぎ替えるという力技でFedoraとWindowsを切り替えているので、Dual Bootできるようにハード側の整備をしなくては。
bootの問題が解決したし、日本語入力の問題もほぼ解決したようなので、-o3化を進めていきます。
その過程で出てきた新しい問題が、
doxygen: symbol lookup error: /lib64/libclang-cpp.so.13: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE8_M_eraseEmm, version LLVM_13
なにやらわけのわからない名前のシンボルが見当たらないと苦情が出ます。
この問題は結構な数のモジュールで発生している模様なので解決しないとなりません。調べてみると2017年頃にGCCのバージョンが変わったことで一時発生していたようですが、ここ最近は話題になっていない模様。
もう一度エラーログを見直すと、libclang-cpp.so.13に有るはずのものが見当たらないのが問題だと言われてます。そう言えばclang自体も早々に-o3化を済ませていたのでしたが、もしかしてと思いdnfを利用してclang-libs.x86_64をインストールし直したところ問題解決!。
結局のところこの問題のシンボルは空のエントリかなにかで、-o3の時に「無駄だから削除」となったのでしょう。-o3の意外な副作用でびっくりさせられましたが、他にも起きているかもしれません。改めて問題が起きたらその時に考えましょう。
この問題が解決した後はスムーズに進行。CPUが同じ第4世代とは言え、i5からi7になったことと、メモリーが8Gから16Gになったことでリビルドにかかる時間も25%ほど短縮されたようです。
firefoxが2.5時間、thunderbirdが1.5時間、Kicadも1.5時間くらいですから、このくらいなら待てますね。ちなみに33時代のfirefoxはリビルドに8時間かかってましたが、あれは何だったのかな。
残る常用する大物はlibreofficeだけど、関係モジュールが多数なので準備が面倒。まぁこの週末に退治しますか。
日を置いて再挑戦したところ全てがスムーズにいくようになりました。
結局はgrub2の問題だった模様。インストール時に入るバージョンは2.06-6なんですが、問題なく使えている現在は2.06-10。
実は途中で2.06-8ってのが有って、こついが悪さしていた模様です。実際に吹っ飛んだ時のアップデートリストに入っているのも2.06-8ですしね。
なにはともあれ無事にアップデート後に無事に再起動できるようになりました。34時代のデーターは書き戻したので、後は恒例の-o3祭りですね。相変わらず一進一退で現在残600余りと、まだ先は長そうです。
それはそうとして、gtk環境が支配するアプリケーションでは今のように日本語が入力できるのですが、KDE環境下だとibus自体が不調のようで入力不能に。
audacityなど日本語を使いたくなる場面が多いので、logでも読んで調べてみないと。
Kicadの方が一段落したので、本当の目的であるFedoraの環境構築。それが今回はとても手強い。いままでの環境との違いと言えば、いままではBIOS経由だったのが、今回からはUEFI経由のBootとなったくらいのはずなんですが、謎の現象が起きていて全く落ち着きません。
インストール自体はUSBメモリースティックにインストーラーパッケージを入れてやってそこから起動するだけのことで、難しいことはありません。ものの20分もあれば終わるくらいのお手軽なもの。
ところが、Fedora恒例のインストール後のUpdateをかけるとあっという間に起動不能となります。「Boot Sector not found…」てなメッセージが出るのでどうにもなりません。
一番最初は画面が一面「水色」となる現象が出たので、ビデオカードの不調で吹っ飛んでドライブがこけたのかと思ったのですが、どうも違う様子。だいたい同じハード構成のWindowsはクリーンインストール後は実に安定しているので、ハード系の問題では無いはず。
ドライブの構成の問題かと思い、完全手動構成、完全自動構成、LVM使用の自動構成といろいろと試しましたが、どの構成でもUpdate終了後の再起動ができなくなる事にはには変わりなく、しかもネット上にもほとんど情報がなくて大弱り。
謎なので、VM上にインストールしてupdateしてみましたが、全く問題が発生しません。
起動系をいじくるのはgrub2しか無いのでgrub2の更新をせずに他を更新した場合にどうなるのか試してみましょう。
折角の英語環境があるので、Msysでの構成にも挑戦してみましたが、豪快にMsys2の環境生成で失敗。なんとかのバージョンがとか、シグネチャがとか多数文句が出ます。
これは言語環境では無く、そもそも引っ張ってくるMsys2のバージョン違いが問題なんでしょうけど、別世界から引っ張ってるのでしょうかね。とても謎。いつも言っているように、元の開発者グループがどうやってパッケージを生成しているのか本当にわかりません。
5.1.12についてはこれで一段落かな。次はLinux側で作業しますか。それ以前にLinux環境を再構築しなくてはならないので、少し面倒だな。
vcpkgの作成で結局7時間ほどがかかりました。その後のビルド作業中にglewとdoxygenが無いと苦情が出たので都度追加。結局このビルドの為にインストールしたのは、
Visual Studio2019の機能としてcmakeとgitは含まれている感じなので、あえてインストールしておく必要は無かったかもしれませんが、vcpkgやKicadのソースの取り出しに使用したので、VSとは別に入れておいた方が良い気がします。
さて、警告は多数出たのですが、Build自体は2.5時間ほどで無事終了です。本体より環境構築の方が時間がかかっているのは癪なんですけどね。
相変わらずインストール用パッケージが生成されていないのは謎というか、反省点なのですが、まぁ需要が全くない自己満足ビルドなのでこれでOKかな。と言いたいところですが、元がWinbuilderと言っている以上インスートラーパッケージまで生成してくれないと不満が残ります。ビルドログに何か残っているかもしれませんね。
さて次はVM上の英語版Windowsではなく、英語環境として追加したユーザーアカウントで試したら何が起きるのかを確かめないと。
MSの開発用ライブラリから期間限定使用のWindows11の環境をダウンロード。VMplayerをインストールしてさっそく使用開始。
起動した画面はあちこちにあるサンプル通りの画像です。(左上になんか出てますが、そこはご愛敬ってことで)
開発テスト用ってことで最初からVS2019が入っているので、必要なのはcmakeなどのCLI系C++の開発ツール群をVSに追加してやるだけです。後はgitを入れて、PATHを通し、vcpkgのclone化と使用開始手順。次に環境変数VCPKG_DEFAULT_TRIPLETにx86-windowsをセットして、.\vcpkg install boost cairo curl glew gettext glm icu libxslt ngspice opencascade opengl openssl python3 wxpython wxwidgets zlib
を書いてある通りに実行。流石にVM上なので結構時間がかかります。と言うか5時間経過してますが、まだこの手順が終了しません。しかしこちらの環境だとエラーになることもなく進行しているので、やはり元から英語環境でないとダメなんですね。
ちなみに日本語環境下でcp1251やcp65001を試してみましたが、同じエラーが出ますので、一時的対処ではダメなようですね。何か他の環境変数による指定が効いているのかもしれませんが、ぱっと見では見当たらない。
気になったので少し調べてみたら、ユーザー毎に言語系を変えられるようです。だとすれば英語系を使用する新しいユーザーアカウントを作ってそっちで作業すれば良かっただけのことだったかもしれません。後で試してみますか。
まぁ、Windows11に触れたのでとりあえず良しということですね。さて181/184で停滞しているvcpkgの処理。早く終わらないかな。
PCの再調整が終わったので、再度rebuildに挑戦。
本家を見ていたら「これからはWindowsの場合はMSVCだぜ!」ってな表記があったのでVSを入れて段取り開始。
VSのような便利なシステムをフルで無償利用させてくれるMSの太腹に感謝です。
vcpkgの構成の途中でwxpythonの構成でerror停止。msys2利用でも問題になるのですが、vcpkgでもエラー!
内容は構成の途中で文字コード変換からみでエラーになることが分かりました。なら対処法はと探ってみるとwxpythonのフォーラムで「よくわからないので、対処無し」と7月に書き込まれて放置状態。たぶん文字コード変換の必要のない環境では発生しない問題なのでしょう。
かくなる上は文字コードを英語に変更して試す必要があるのですが、これだけの為に再インストールは辛いな。普段使いにも不便になるし。
というわけでテスト用のWindows10イメージがマイクロソフトから提供されているので、VMに食わせて再挑戦してみますか。
もともとの始まりはうっかり「復元パーテーション」を消してしまったことから始まっているのですが、なんだかんだで完全クリーンインストールとなったのでだいぶ動きが軽快になりました。
このPCは当初Wind0ws8でしたが、無料アップグレードのおかけで8->8.1-10と来て、Windows10の各種エディションを経由して20H1までアップグレードで来ていたのでした。
また途中であれこれインストールしたりアンインストールしたりで結構なゴミが溜まっていたのでしょう。
近頃のアプリケーションやドライバーは更新確認を言い訳としてやたらに常駐部を残してくれるのでシステムとしては無駄が多くなります。なので、その手のソフト(Abodeとかアドビとか…)を入れなければだいぶ動作が軽快になりますね。更新確認なら起動時に一発だけで良いと思うのですが、少なくないソフトが常駐部を残してくれるのでシステムメモリーを汚します。
常駐しているからには更新確認以外に動作状況の確認やら競合ソフトの状況なんかを開発元に送信しているのではないかと疑ってしまい、できるだけインストールしたくない状況となります。これは開発元としてもあまりよい状況では無いと思うのですがどうなんでょうね。
自宅に持ち帰ったPCの調子が良くありません。謎のプチフリーズが多発するし、他にもなにか不安定。まぁ、HDD-SSD(A社)-HDD-SSD(B社)とイメージコピーで来ているので、構成的に無理が発生しているのかも。
なので思い切って再インストールすることにします。まぁいまだとPCの中身もだいぶ減っているのでバックアップも楽だしね。
11/18 追記
クリーンインストール自体はさほど時間もかからずに終了。しかしライセンス認証のためにMSのアカウントと紐づけした時にDesktopやMyDocumnetなどがOneDirve上のフォルダー設定にされてしまい、解除できない。(移動できないフォルダーがあるとかなんとか)
旧のデーターはまだ残したままなので、今晩にでも再インストールしなくちゃ。
それにしても、どこでそんな設定になったのやら。お節介で迷惑な仕様だ。