カテゴリー: ソフト関係

KiCAD V6その2

メインフィールドであるFedoraにRawideではありますが、正式に6.0が来たのでソースをチェック。いつもの所にお馴染みのnewstroke_font.cppを発見。ならばと早速ファイルを入れ替えてrebuild。結果は予想通りで、全部の文字を確認したわけではありませんが、ざっと見た範囲では幅の問題が解決しています。

と言うことは、Windows側でもまだRebuildはやる価値ありということで、再びがさごそ。
しかしMsys利用のWinbuilderは対応が5.12で止まっています。PKGBUILDの中身をいじれば良いのでしょうが、正規に提供していないということは何か問題があるんだろうと思わせます。

ならば丁度よいと思い英語環境のユーザーを追加してVisual Studio利用での作成に挑戦。
しかし、vcpkgの処理中にwxPythonの文字コード問題が発生してエラー停止。CP1251でも結果は一緒です。
普通に日本語環境で試した時と同じ結果で、使用言語を英語にしただけではベースの文字コードが変わらないので問題は解決しない模様なんだけど、全体の文字コードベースをUTF8にする方法が有るらしいので、いったんそちらを試してみますか。

それにしてもこのsh●tなパッケージを使い続けている理由が分からないなぁ。ベースのpythonでもV2からV3への移行で大問題が発生しているので個人的には関わりたくない言語です。とは言え人気が有り、高校の情報の授業でのプログラミングの題材として利用されていのをよく見かけますので、とっつきやすいんでしょうかね。

と言うわけで、またMSから英語版Windows11の開発環境イメージを落としてきてそちらの環境で試してみましょう。

Fedora35その4

大量のKDE5のアップデートが来ました。5.89->5.90なのですが、rebuildで問題発生。

当初kf5-kconfigのrebuildで余計なファイルであるlibKF5ConfigQml.so.なんとかが邪魔と怒られます。なのでspecファイルに余計な奴らを削除するように指示を追加して問題解決。
ところがその後、少なくないファイルのrebuildがfailで止まります。5.89のときは無かった現象なので何が起きたのかBuild Logを読んでみます。
すると…

CMake Error at /usr/lib64/cmake/KF5Config/KF5ConfigTargets.cmake:89 (message):
The imported target "KF5::ConfigQml" references the file
"/usr/lib64/libKF5ConfigQml.so.5.90.0"
but this file does not exist. Possible reasons include:

まさしく先程のkf5-kconfigのrebuildで消したファイルが無いと怒られています。
再びkf5-kconfigのspecファイルを変更してlibKF5ConfigQml.soとかなんとかをcoreファイルとdevelファイルに入るようにしてrebuildして再インストール。
そうしたら問題が解決したのでした。

  • kf5-kcompletion-5.90.0-1.fc35.src.rpm
  • kf5-kconfigwidgets-5.90.0-1.fc35.src.rpm
  • kf5-kcontacts-5.90.0-1.fc35.src.rpm
  • kf5-kfilemetadata-5.90.0-1.fc35.src.rpm
  • kf5-kglobalaccel-5.90.0-1.fc35.src.rpm
  • kf5-knotifications-5.90.0-1.fc35.src.rpm
  • kf5-kservice-5.90.0-1.fc35.src.rpm
  • kscreen-5.23.5-1.fc35.src.rpm
  • plasma-systemmonitor-5.23.5-1.fc35.src.rpm
  • plasma-workspace-5.23.5-1.fc35.src.rpm

以上がこの問題に引っかかっていたファイル。結構大物が含まれています。

おそらくはrebuildなんて酔狂なことをしなければ問題にはならなかったのでしょうけど、検証ってどうなっているのやら。Bugzillaに報告を上げたほうがよいのだろうか?

KiCad V6

年末ぎりぎりのタイミングでVer.6が公開されました。私のメインフィールドであるFedoraはRawhideが6.0rc1で、本提供は5.12で止まっていますので、Windows版でテスト。

  • SCH V6
  • PCB V6

噂通り、そのままの状態で日本語が表示されます。なんとなくカナ部と漢字部の幅の割当が間違っている気がしないでも無いのですが、例の大騒ぎをしなくても良いのは助かります。まだソースは見ていないのですが、newstoke_fontを入れ替えれば解決するのかな?

Fedora側の-o3処理祭りがようやく7割方終わったところなので、片付いたら試してみますか。
その前に現在SSDをつなぎ替えるという力技でFedoraとWindowsを切り替えているので、Dual Bootできるようにハード側の整備をしなくては。

Fedora35その3

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だけど、関係モジュールが多数なので準備が面倒。まぁこの週末に退治しますか。

Fedora35その2

日を置いて再挑戦したところ全てがスムーズにいくようになりました。

結局はgrub2の問題だった模様。インストール時に入るバージョンは2.06-6なんですが、問題なく使えている現在は2.06-10。
実は途中で2.06-8ってのが有って、こついが悪さしていた模様です。実際に吹っ飛んだ時のアップデートリストに入っているのも2.06-8ですしね。

なにはともあれ無事にアップデート後に無事に再起動できるようになりました。34時代のデーターは書き戻したので、後は恒例の-o3祭りですね。相変わらず一進一退で現在残600余りと、まだ先は長そうです。

それはそうとして、gtk環境が支配するアプリケーションでは今のように日本語が入力できるのですが、KDE環境下だとibus自体が不調のようで入力不能に。

audacityなど日本語を使いたくなる場面が多いので、logでも読んで調べてみないと。

Fedora35苦戦中

Kicadの方が一段落したので、本当の目的であるFedoraの環境構築。それが今回はとても手強い。いままでの環境との違いと言えば、いままではBIOS経由だったのが、今回からはUEFI経由のBootとなったくらいのはずなんですが、謎の現象が起きていて全く落ち着きません。

インストール自体はUSBメモリースティックにインストーラーパッケージを入れてやってそこから起動するだけのことで、難しいことはありません。ものの20分もあれば終わるくらいのお手軽なもの。

ところが、Fedora恒例のインストール後のUpdateをかけるとあっという間に起動不能となります。「Boot Sector not found…」てなメッセージが出るのでどうにもなりません。

一番最初は画面が一面「水色」となる現象が出たので、ビデオカードの不調で吹っ飛んでドライブがこけたのかと思ったのですが、どうも違う様子。だいたい同じハード構成のWindowsはクリーンインストール後は実に安定しているので、ハード系の問題では無いはず。
ドライブの構成の問題かと思い、完全手動構成、完全自動構成、LVM使用の自動構成といろいろと試しましたが、どの構成でもUpdate終了後の再起動ができなくなる事にはには変わりなく、しかもネット上にもほとんど情報がなくて大弱り。

謎なので、VM上にインストールしてupdateしてみましたが、全く問題が発生しません。

起動系をいじくるのはgrub2しか無いのでgrub2の更新をせずに他を更新した場合にどうなるのか試してみましょう。

Kicad 5.1.12再挑戦その4

折角の英語環境があるので、Msysでの構成にも挑戦してみましたが、豪快にMsys2の環境生成で失敗。なんとかのバージョンがとか、シグネチャがとか多数文句が出ます。

これは言語環境では無く、そもそも引っ張ってくるMsys2のバージョン違いが問題なんでしょうけど、別世界から引っ張ってるのでしょうかね。とても謎。いつも言っているように、元の開発者グループがどうやってパッケージを生成しているのか本当にわかりません。

5.1.12についてはこれで一段落かな。次はLinux側で作業しますか。それ以前にLinux環境を再構築しなくてはならないので、少し面倒だな。

Kicad 5.1.12再挑戦その3

vcpkgの作成で結局7時間ほどがかかりました。その後のビルド作業中にglewとdoxygenが無いと苦情が出たので都度追加。結局このビルドの為にインストールしたのは、

  • cmake
  • git
  • vcpkg(オリジナルではなく、kicad用として提供されているものが必要)
  • swigwin
  • glew
  • doxygen

Visual Studio2019の機能としてcmakeとgitは含まれている感じなので、あえてインストールしておく必要は無かったかもしれませんが、vcpkgやKicadのソースの取り出しに使用したので、VSとは別に入れておいた方が良い気がします。

さて、警告は多数出たのですが、Build自体は2.5時間ほどで無事終了です。本体より環境構築の方が時間がかかっているのは癪なんですけどね。

相変わらずインストール用パッケージが生成されていないのは謎というか、反省点なのですが、まぁ需要が全くない自己満足ビルドなのでこれでOKかな。と言いたいところですが、元がWinbuilderと言っている以上インスートラーパッケージまで生成してくれないと不満が残ります。ビルドログに何か残っているかもしれませんね。

PCB sample

さて次はVM上の英語版Windowsではなく、英語環境として追加したユーザーアカウントで試したら何が起きるのかを確かめないと。

Kicad 5.1.12再挑戦その2

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の処理。早く終わらないかな。

Kicad 5.1.12再挑戦

PCの再調整が終わったので、再度rebuildに挑戦。
本家を見ていたら「これからはWindowsの場合はMSVCだぜ!」ってな表記があったのでVSを入れて段取り開始。
VSのような便利なシステムをフルで無償利用させてくれるMSの太腹に感謝です。

vcpkgの構成の途中でwxpythonの構成でerror停止。msys2利用でも問題になるのですが、vcpkgでもエラー!
内容は構成の途中で文字コード変換からみでエラーになることが分かりました。なら対処法はと探ってみるとwxpythonのフォーラムで「よくわからないので、対処無し」と7月に書き込まれて放置状態。たぶん文字コード変換の必要のない環境では発生しない問題なのでしょう。

かくなる上は文字コードを英語に変更して試す必要があるのですが、これだけの為に再インストールは辛いな。普段使いにも不便になるし。

というわけでテスト用のWindows10イメージがマイクロソフトから提供されているので、VMに食わせて再挑戦してみますか。