Chromiumのbuildは手強い

alienさんのディレクトリーに,ChromiumのSlackBuildスクリプトやパッチ一式があります.そこで,Google-Drive-OCamlFuseをSlackware ARMで動かした余勢をかって,buildに挑戦しました.

とりあえず,chromium.SlackBuildスクリプトを走らせたら,なんかエラーが出たので,エラーメッセージを手がかりに,Google-Drive-OCamlFuseのときと同様に,-gnueabihfを付けたら,そこは通りました.

--- chromium.SlackBuild-org 2020-11-12 12:55:07.023680300 +0900
+++ chromium.SlackBuild 2020-11-12 12:55:54.442478873 +0900
@@ -893,9 +893,9 @@
   # Take care of Debian/Ubuntu related linker issues:
   echo "/usr/lib/${SYSROOT_TARGET}-linux-gnu/nss" >> \
-    build/linux/${SYSROOTDIR}/etc/ld.so.conf.d/${SYSROOT_TARGET}-linux-gnu.conf
+    build/linux/${SYSROOTDIR}/etc/ld.so.conf.d/${SYSROOT_TARGET}-linux-gnueabihf.conf
   ln -s libsqlite3.so.0 \
-    build/linux/${SYSROOTDIR}/usr/lib/${SYSROOT_TARGET}-linux-gnu/libsqlite3.so
+    build/linux/${SYSROOTDIR}/usr/lib/${SYSROOT_TARGET}-linux-gnueabihf/libsqlite3.so
 fi
 --- Compile ---

しかし,その後,config-third-party-ffmpegとやらで,エラーが出てしまい,手がかりがないのでお手上げです.

しばらくこのまま放置します.

2020年11月13日(金): diffの内容が,ちゃんとペーストできていなかったので手で修正しました.

Google-Drive-OCamlFuseのときは,gnueabiにしましたが,やはりgnueabihfが正しかったのかも知れません.

Raspberry Piで暮らせるか (3) SSDで解決

プチフリーズ的な問題は,SDカードをルートドライブにしているからに違いないと解っていたので,SSDに替えることにしました.

もともと32GBのSDカードで動かしていたので,128GBもあればいいのですが,今SSDが値崩れ状態のようで,960GBで,USB3.0エンクロージャーに入ったものが,1万円しないので,大きすぎな嫌いはありますが,先々の使い回しもできるので購入しました.

今日(2020年11月10日)届いたので,早速セットアップしました.すでにブートローダーがUSBドライブ起動に対応しているので,最初のmsdos(vfat)のパーティションにSDカードの最初のパーティションを,残る適当なパーティションをLinux(ext4)にして,残るSDカードのLinux部分をコピーということで大体作業は終わりです.

ターゲットマシンをSDカードでブートさせて,その上でコピーもできますが,/devなど,生きているときと死んでいるときで中身が違うのがありますから,別のLinuxマシンにSDカードとSSDをマウントして,rsyncなどでコピーするほうが楽です.

コピーした内容のうち,2つのファイルだけ変更しなければなりません./etc/fstabと,/boot/cmdline.txtです.今回どちらも,/dev/sdaなんとかでなく,UUIDを入れてみました.blkidで表示される長ったらしいやつです.

SSDをつなぎ,SDカードを差し込まないで,あとは,無事起動することを祈って電源を入れたらあっさり起動しました.

ほとんど問題なく使えます.プチフリーズ的なことは一切起きません.ただ,今どきのパソコンに比べれば,同等とまでは言えず,ほんの少し遅いノートパソコンくらいかなという感じです.しばらく様子を見てみたいと思います.

Slackware ARMが走るサーバー(左: Raspberry Pi 4 Model B RAM 4GB)と今回購入したRaspberry Pi OSの走るWS (同8GB).撮影のため無理やり寄せています😥

Slackware ARMでGoogle Driveを使う(成功!)

手順をまとめました.

四苦八苦していた,Slackware ARMへのGoogle Driveのマウントですが,成功しました.

まず,失敗のページのopamを使ったgoogle-drive-ocamlfuseまでのインストールは正しかったです.

にもかかわらず,認証のために引数なしでgoogle-drive-ocamlfuseを立ち上げてもエラーが出てします.

結論的にはこのエラーの原因は,このマシンのホームディレクトリーに,大昔のx86 32bit時代にいじった .gdfuse ディレクトリーが継承されていたことによります.

エラーが出たら,Google Driveを使いたい人のホームディレクトリーで,

rm -rv .gdfuse

として,古い設定ファイルを消します.

そして,以降の手順は,前のページでも参照した,

のほぼその通りです.ただし,もともとSlackware ARMにはFirefoxはないので,Firefoxのかわりに,www-browserという名前の以下の内容のファイルを実行可能にして,PATHの通るところに置きます.

#! /bin/sh
echo $* > /dev/stderr

上記Qiitaの例では,ホームディレクトリーに置いて,そこにパスを通していますが,筆者の場合はもともと$HOME/binにPATHを通しているのでそこに置きました.

.gdfuseのない状態で,google-drive-ocamlfuseを起動すると,長ったらしいURLが表示されますから,それを手元のブラウザにコピペして認証すればOKです.

KVM upgrade断念

だんねん残念ながら,あきらめて,backupから,元に戻しました.

最大のネックは,GNOMEが,buildの環境をlibtoolからmeson (ninja)に変更したことです(当社調べ).たとえばglibだと2.59.xと2.60.xの間でその変更があります.マイナーバージョンが1つ上がってこんなに変えて良いのかとわめきたくなります.GTK+3にも同様に境界があり,最新のソフトは,meson対応のGTK+やglibを要求し,逆に旧式のソフトは,libtool時代の.la拡張子のlibtool archiveを要求します.

で,記憶違いかも知れませんが,qemuは,依然としてlibtool archiveを要求するのに対し,virt-managerはmeson対応のGTK+を要求します.

まあ,ちゃんとメモを残したわけではないですが,そんな感じだったと思います.もうしばらく待って,世の中のdistroが,meson & ninja対応のGNOMEパッケージを使用するようなり,そういうのにupgradeしてから挑戦し直します.

それにつけても,ninjaって名前はなんとかなりませんかね.ネット検索しても「忍者」の情報ばかりかかります.スペイン語圏の人たちはninjaを「ニンハ」って読むんでしょうか

ネット検索すると,どうもそのようです.

KVM回りのupdateに着手

結局,久しぶりに取り組んでみることにしました.しかし,なかなかたいへんです.

以前buildしたときと比較すると,

  1. 必要なライブラリーやツールが増えた
    • まあ,バージョンが進めばありがちなこと
  2. glib関係のライブラリーのバージョンが相当進んだ
    • それなのに,sbopkgでは一部のパッケージのupdateが止まっている
    • よりによって,GNOMEがlibtool archive (.la)の使用をやめたので大混乱
  3. Python2がobsoleteとなった

などの問題に遭遇しています..laがなくなったことは,訳解らずにbuildしている人間にとっては大混乱を引き起こしました.SDL2のように,すでに,.laがなくても大丈夫なライブラリーもありますが,libvirtなどは,xxx.laがない,って文句を言って止まります.今回のupdate作業では,glibは最新のものでなく,2.58.xを使用することにしました.

virt-mangerのbuildまでいきましたが,起動すると,”gi”というモジュールがないといって止まります.明日以降取り組むことにします.

追記(2020/10/14)

giの件は,大きな問題ではなく,

pip3 install pygobject

で解決しました.が,それだけの問題ではなかったです.