メモリー追加

順調に進んでいるかに見えるrebuild。しかし時々謎のエラーで処理中のconsoleプロセスごとすっ飛びます。エラーログを確認すると、どうやらメモリー不足らしい。

16Gも積んでいるのになんでと思ってメモリー状況を確認すると、

@localhost:/$  free
           total        used     free      shared  buff/cache   available
Mem:        16208832     2576824     4024192       49256     9996988    13632008
Swap:        8388604      29828     8358776

と見慣れないswapという項があって、すでに最初から半分食われています。そういえば40のあたりから物理媒体でのswapの代わりにzramという、いわばramdiskをswapとして使用するようになっている事を思い出したのでした。で、デフォルトでの容量設定が搭載メモリーの半分の設定とか。

だから大物をrebuildするとメモリー不足に陥って吹っ飛ぶのですね。ならばとzramの最大値を4Gに制限したらどうかと思い、設定してみましたが状況変わらず。

家電量販店でのポイントが余っているので、メモリーを増やしてやることにしましたが、このマザー(Asrock B460)はチップセットが”B460″だからなのか、DIMM Slotが2つしかありません。しかたなく16GのDIMMを2個注文。とは言え1枚6.4k円ですから随分と安くなったものです。

あまりこちら系統は強くない家電量販店のこと、通販で1週間と有り得ないような長納期で届いたのでさっそく交換。

@localhost:/$  free
            total        used    free      shared  buff/cache   available
Mem:        32698944     2878956    23995088       38532     6386460    29819988
Swap:        8388604     1107788     7280816

と無事に増加しました。
その結果、今までメモリー不足ですっ飛んでいた大物のrebuildも平和に進行するようになって一安心。
旧PC時代に時々プロセスが落ちていたのは、これが原因だったのかも。旧PCもメモリーは16Gしか積んでませんでしたから。

それにしても道楽だってのに何やってんだろうな(苦笑)。

Rebuild再開

PC入れ替えになったので、Fedora42が素の状態でインストールできるようになりました。おかげで、今まであった謎の現象がことごとく解消されて快適です。

rebuildはどうかと試したところこちらもスイスイ。なので例によっての野良ビルド開始です。

ただし、-O3には副作用が多いとの記事をよく見かけましたので、今回は-Oは触らずに、-mtune=native -march=native -mfpmath=bothを追加するに留めておきます。

取り掛かったばかりなので、先は長いぞ。それより43の登場のほうが早いかも。それならそれでもいいんですけどね。

cmake QT6の謎

Fedora40にUpgradeしたのですが、各モジュールのrebuildで問題多発。QT6のcmake定義がないとかなんとか。kf6(KDE 6)のメインモジュールやplasma関係のrpmがかなり引っかかります。
いろいろ調べて処置してみるのですがまったく改善されません。

しばらくもやもやしていたのですが、VMに新規インストールしたらどうなるのかと気付きました。
VM player ProがVer.17から個人利用であれば使用できるようになったので早速セットアップ。そしてFedora40をISOイメージからインストールしてあれこれ準備。
ちなみにVMへだと、UEFIでなければインストール不能となっているFedora40が若干の問題だけでインストールができます。

さっそくrebuildしたところ問題なく進行していきます。ならばと思い、/usr/lib64/qt6/cmakeの中身を全部取り出して、VMでない方にコピーします。本来は一つずつどこがどう違うか調べるべきでしたが、一気に上書きしたので何がNGだったのかは不明ですが、rebuildは本番環境でも問題なく進むようになりました。あとはネット関係が引っかかるのを解決できれば問題解決なんだけど、どこから調べていきますかね。現状ではVM上のFedoraの方がスムーズに動きますので。

だからと言って全面的にVM環境下へ移行することも検討しましたが、どうしたってパフォーマンスは落ちますから、正しい選択とも思えません。

さてもう一息頑張りましょうか。

-O3化本当に終わり

SRPMを取り出すツールを作ったので、ついでとばかりに全体の-o3化にとりかかり、なんとか終了しました。

-o3化できたのが1834ファイルで、失敗が123ファイル。失敗の中にはどうにもならない依存関係のある物も含まれていますので、純粋に謎のrebuildエラーで出来上がらなかったのは7割くらいじゃないでしょうか。

それにしてもPythonからみでファイルやディレクトリが見つからないというエラーがたくさんあって、どうもPythonは具合悪いですね。いろいろな依存関係からから多数のバージョンが同居している状態は気持ち悪いです。

ところで-o3化したことで、全体の感じに変化があったのかなんですが、これが少しずついじっていったこともあってよくわからないというのが実態。rebuild時間の短縮とか、ちょっとしたレスポンスの向上などがあるはずなんですが、一気に入れ替えてみないと実感できないなぁというのが正直な感想です。
でも自力でrebuildしたシステムを使用しているわけで、たぶんこれが本来のLinuxの使いたかだよなと自己満足しています。

SRPMの取り出し

と言うわけで早速半自動取り出しスクリプトを作成

#
# エラーリストなどから自動で.srpmを取り出すためのスクリプト
# getsrc.sh

#! /bin/sh
cat $1 | gawk '{ print $1 }'|grep "[0-9A-Za-z]"|grep -v '^setting' > ./temp.txt
cmd=""
spc=" "

for fn in $(cat ./temp.txt); do
        if [ $fn == "RPM" ]; then
                break
        fi
        cmd=$cmd$spc$fn$spc
done

rm temp.txt -f
echo $cmd
dnf download --source --destdir ./SRPMS $cmd

楽ですね。さらに楽だなぁと思ったのは重複している場合やすでにダウンロードしている場合には自動でスキップしてくれる点です。なので、何も考えずにリストを作成してこのスクリプトに食わせてやればOK。
dnfの直前のecho $cmdは確認用でもあるので、無くても問題はないですね。

例えばlist1.txtなるファイルに

tcpdump-4.99.4-1.fc38.x86_64
tigervnc-server-minimal-1.13.1-3.fc38.x86_64
time-1.9-20.fc38.x86_64
tmux-3.3a-3.fc38.x86_64

と言った感じで羅列してやり、あとは

$ ./getsrc.sh list1.txt

これだけで、このディレクトリ内の./SRPMS内に.srpmがダウンロードされます。リストにはバージョン情報は無くてもよいので、単に

tcpdump
tigervnc-server-minimal
time
tmux

でもOKです。
いや、もっと早く気づいていれば楽できたのにな…

-O3化ようやく終わり

Fedora38の三度目のインストール騒ぎ。その際にgroupinstallなど手動でインストールでモジュール類が明確に分かった各種ツール類の-O3化がようやく終わりました。

生成済みrpmの確認用のツールも作ったので、ついでだと言う訳で現在システム内に入っているrpmどもの内どの程度が-O3化されているのか確認してみることに。
その結果インストール済みが6,185モジュールでその内処理済みは3,212モジュールとだいたい半分。

最初から入っていた分でまだupdateが来ていないものがこれだけ有るということになります。もちろん依存関係やどうしても解決できないrebuid時のエラーによって-O3化できない物もあるので未処理分の全部が取り掛かっていないと言う訳ではありませんが、まだ結構残っている感じ。

rebuildエラーになったsrpmから生成されるrpmモジュールを取り出すツールを用意して、この際だからできる分は全部片づけてみますかね。

KiCAD V6その4

どうにか時間が取れたので、本体のbuild開始。30分くらいで終わった気がします。

今回、VSでProjectを開くのにドキュメントと違う方法試したところドはまり。cmakesettings.jsonにswig.exeとpython.exeのありかを書いておけば、特に何も追加指定せずに実行できるはずと、あれこれやりましたがエラーが取れなくて一旦中止。cmakesettings.jsonの書式を勉強しないとだめですね…

今度はドキュメント通りにprojectを開き、ドキュメントにある通りにswig.exeとpython.exeの在処を書き込んでビルド開始。ビルドオプションは生成するオブジェクト毎に分かれています。x86-debug,x86-release,x64-debug,x64-release,MSYS2-x64-debugとあるのですが、x86とMSYS2は使用しないのでx86の2つにだけ追加。

出来上がったのはよいのだけど、何このバージョン表記。またnightlyからソースを引っ張ってきてしまったようだ… 進歩無いな。もう一度6.01のソースをとってくるところからやり直さなきゃ。

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に報告を上げたほうがよいのだろうか?

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