WANDBOARD.ORGのサイトを覗くと、同社のWANDBOARDシリーズに対応したLinux BSPが利用可能であることが判る。

WANDBOARD.ORGからはビルド済みのSDカードイメージとそれをWindows PC環境でSDカードに書き込むためのツールが入ったzipアーカイブをダウンロードすることができる。

実際に10年前に買ったボードが最新のLinux BSPで動くかどうか試してみたところ、問題なく起動した。

同社がバイナリでお試し版を提供しているビルド済みイメージはQTというGUI環境を搭載したものでHDMIディスプレイやUSBキーボードとマウスを接続すればつかえるというもの。

本サーバーはwebサーバー専用なのでGUIは必要ないので、あっても構わないけど、Full HD対応のディスプレイをサポートするためにメモリの大半がディスプレイシステム用に予約されてしまうので、自分の目的にあったBSPを再構築する必要がある。

WANDBOARD用のlinux BSPは、Freescale社由来のyoctoベースのcommunity BSP環境でサポートされており、誰でもダウンロードして利用できる。

WANDBOARD社のサイトからWANDBOARD用のWIKIページがリンクしてあるので、そこにBSPの場所やダウンロード方法やビルド方法が簡単に記述してある。

それを参考にやってみたところ問題なくビルドと動作確認ができたので、ここに記録しておくことに。

WIKIページには安定版と最新版の２つのcommunity BSPダウンロード方法が記載されているが、いろいろと最新でないと困るので最新版を試してみた。

ビルドに使用する環境は手元のWindows PC上にインストールしたVMWare上のUbuntu 18.04LTSを使用した。

WIKIページでは具体的には記載していないが、yoctoベースのBSPをビルドするには、予めUbuntu環境にデフォルトではインストールされていない依存パッケージをインストールしておく必要がある。

(1) yocto BSPの依存パッケージのインストール

Ubuntu 18.04LTSにログインして、下記を実行する。

引用：

これはFreescale社のyocto BSPの使い方を記載したドキュメント"i.MX Yocto Project User's Guide"からの引用。

これで必要なUbuntu環境は出来たので、yocto BSPをダウンロードすることに。

(2) repoのインストール

community BSPは複数の開発者のレポジトリの集合体であるのと、それぞれの開発社のレポジトリの特定のリビジョンでないと同一ビルドの再現性が得られないため、repoというGoogleがAndroid開発者向けに提供しているツールを使用してそれらのレポジトリを自動的にダウンロードする方法が採用されている。

そのためにまず、Googleのサイトから最新のrepoをインストールするか、Ubuntuで予め用意されているrepoパッケージを導入する必要がある。

手元のUbuntu 18.04LTS環境では、前者だとUbuntuのPythonではバージョンが古すぎて怒られたので、後者の方法を取る必要がありました。


下記を実行する。


引用：

これでrepoコマンドが使用できる。

(3) Community BSPのダウンロード

WANDBOARDに対応したCommunity BSPをrepoを使用してダウンロードする手順は下記の通り。

予めgitを使用する上で必須の設定をするために、下記を実行。

引用：

これをやらないと怒られるのだよね。

元々gitレポジトリをダウンロードするのは、それをローカルで修正したり更新して自分のレポジトリを作っていくので、その際にコミットログに記載されるユーザー名とメールアドレスが必須になるという寸法。

実際にはコミットログに記載されるだけで、その設定内容が公表されることはないのでご安心を。ちょっと開発者の仲間入りした気分になるよ。

続いて本題のCommunity BSPのダウンロードは下記の通り。



引用：

最初のrepo initコマンドはyocto BSPを構成するのに必要なgit レポジトリの所在とリビジョンを記載したmanifestレポジトリだけをダウンロードするので直ぐに終わるけど、最後のrepo syncコマンドは記述されたgit レポジトリを全部ダウンロードするので時間がかかります。

これが終わればCommunity BSPのローカルクローンが出来たことに。

(4) Community BSPのbuildディレクトリ作成

ダウンロードされたyocto BSPはサポートするターゲットボード固有のconfigファイルとターゲット固有もしくは共通のパッケージビルドのためのレシピから成ります。

なので、特定のターゲット用のBSPをビルドするには、どのターゲットとどのようなパッケージをOSのファイルシステムにインストールするかを指定しないといけないことになります。

Freescaleの場合は、専用のスクリプトが用意されていて、それを使用することで最小限の手間でビルドディレクトリを作成することができます。

WANDBOARDの場合は、WIKIに書かれているのとは masterブランチを使用したこともあって違っていました。WANDBOARDはハードウェアでどのボードかを自動的に判別できる手段を提供しているので、それを利用することでWANDBOARD全部を包含してサポートするBSPイメージを作成することになります。

BSPダウンロードの後、下記のコマンドを実行します。

引用：

実行すると利用契約の承諾が求められYを入力しないと中止されるので注意。

実行し終わると環境設定がされた状態でbuildディレクトリにカレントディレクトリが変わり、ビルドが出来る状態になります。

(5) BSPのビルド

GUIパッケージを含まない最小限のパッケージで構成されるBSPをビルドするためには、下記を実行します。

引用：

実行すると、設定したMACHINE構成に対応するレシピがスキャンされビルドするパッケージが依存関係ツリーの枝葉から順にビルドされて、最終的に根っこのcore-image-minimalパッケージがビルドされて完了します。

各パッケージのビルドに必要なソースコードレポジトリがダウンロードされるため不確定の時間が要するため、初回のビルドは長時間かかります。以降のリビルドでは既にダウンロードされたソースコードレポジトリはローカルにダウンロードされたものが参照されるため最短時間で済みます。

ビルドが終わった時の状態は下記の様になります。

引用：

ビルドが終わると生成物は tmp/deploy/images/wandboard配下に下記の様なファイルができます。

引用：

あとはこれをSDカードに書き込むだけ。

(5) BSPイメージのSDカードへの書き込み

Ubuntu環境であれば、SDカードをカードリーダーに挿して、予め自動マウントされたパーティションのデバイス名を調べます。

引用：

これでSDカードのデバイス名が/dev/sddだということがわかります。末尾の番号はパーティション番号に対応するので、ストレージ先頭から全体をアクセスできるのはそれを省いたパス名になります。

上記の例で、SDカードにBSPイメージを書き込むために下記を実行します。

引用：

BSPイメージは圧縮されているので、それを解凍しながらSDカードに直接書き込みます。

WANDBAORDがビルド済みBSPと一緒に提供しているWindows用のSDカード書き込みツールを使用しても同じことができますが、その場合には予め、gzipコマンドで解凍したファイルを用意する必要があります。

(6) BSPイメージのターゲットでの動作確認

BSPイメージを書き込んだSDカードをホストPCのカードリーダーから外して、WANDBOARDのCPUモジュール上にあるSDカードスロットに差し込み、デバッグコンソールシリアルをホストPCにNULLモデムケーブル(クロス接続ケーブル）で接続し、ターミナルエミュレータでボーレイト115200かつ8bit パリティ無しで開いておきます。

上記の状態でWANDBOADに電源を供給すればSDからu-bootが起動し自動的にlinuxが立ち上がるはず。

実際に確認した際のログは下記の通り。

引用：

予想通り、大部分のメモリを空き状態にすることに成功。

これなら現行のIBMノートPCより空きメモリ量は多い感じ。

ここからカスタマイズを始めることに。

んじゃまた。

core-image-minimalはyoctoの最小構成BSPイメージなので、サーバーとして使うにはnetwork関連に追加しないといけないパッケージすら含まれていない。

そこでFreescale社が独自に追加したサーバー用のBSPイメージパッケージとして、fsl-image-network-full-cmdlineというのがあるのでそちらを使うことに。

デフォルトではnetworking関連のパッケージレシピへのサーチパスが通っていないので、conf/bblayers.confのmeta-openembeddedに関するサーチパスに下記の行を追加する必要があった。

引用：

もともとはsource/base/conf/bblayers.confがコピーされるだけなので、そっちを直しておけば良いのかも。

bitbake fsl-image-network-full-cmdlineを実行したら、順調にいくかに見えたが下記のエラーでビルドが失敗することが判明。

| 20 | # error "LTTng-modules requires CONFIG_KPROBES on kernels >= 5.7.0"

最新のcommunity BSPはkernel version 5.10を採用しているので、その場合、LTTng kernel moduleがkprobeというkernelのオプション機能を必要とするぽい。

とりあえず暫定的に、menuconfigを開いて問題のconfigオプションをインクルードするように変更。

引用：

これでいけた。

sshdも入っているので、リモートでログインして作業ができる。

問題はセルフビルド環境が入っていないので、それを加える必要がある。

それと今時 init sysvは古いだろうということで、systemdに切り替えることに。

buildディレクトリのconf/local.confに下記を追加。

引用：

セルフビルド環境に必要なパッケージを導入するために、更に下記を追加。

引用：

最初の行はセルフビルド環境とは直接関係ないけど、昨今の大容量USBメモリは4GiBを越えるような動画ファイルを扱えるようにexfatフォーマットされているので、Windows PCからそうしたUSBメモリでファイルを交換しようとするとlinux側ではサポートされていないためユーザーランドでexfatを扱えるようにした拡張パッケージを導入するためのもの。これで指定したディレクトリにexfatフォーマットの媒体をmountしてアクセスできるようになる。

とりあえず現行のサーバーで使用しているソースとかコンテンツを含んだ圧縮アーカイブが4GiBを越えるファイルサイズなので、これは必要だった。

2行目を加えるとUbuntu PCのようにオープンソースソフトウェアをソースからビルドできる最小限の環境が入る。一部のオープンソースでは更に別の開発ツールやライブラリに依存するのでそれらをソースからビルドしてインストールするのに必要。

これでビルドしてできたイメージをSDカードに書き込んで起動を確認し、コンパイラツールチェインとか基本的なセルフビルド環境が使用できることを確認。

次は、現行のサーバーで使用しているオープンソースソフトウェアをビルドしていく作業。

P.S.

init sysvからsystemdに変更すると今風にはなったもののバックグラウンドで起動するタスクが増えるので空きメモリ量が現行のIBM ノートPCと変わらなくなった（´Д｀；）

元のinit sysvに戻すかも。

セルフビルド環境ができたので、現行サーバーで使用しているオープンソフトウェアをビルドしてインストールするだけ。

最初に無難な、apache web serverから

現在使用しているapache2だとapr, apr-iconv, apr-utilsというパッケージを予めビルドしてインストールしないとapache2本体がビルドできないので先にそちらをビルド＆インストール。

これは問題なくできた。

次はxoops関連で必要な、mysqlの導入。

現行サーバーではubuntuで提供されているmysqlパッケージをそのまま使用しているが、yoctoでもmysqlはサポートされているが、バージョンが異なるのと、パッケージを追加するのにまたビルドし直さないといけない（ビルドしたrpmパッケージだけもってきてインストールするという手もあるかもしれないが実績ないので却下）ので面等なので、ソースからビルドすることに。

mysql は現在ではOracle傘下なので、有償の商用版とオープンソース版があり、後者はcommunity versionとして従来通りソースコードが提供されている。

それをダウンロードすればいいわけだが、wgetでやってみたら怒られた（´Д｀；）

root@wandboard:/mnt/share/home/webadm# wget https://downloads.mysql.com/archives/get/p/23/file/mysql-5.5.52-linux2.6-i686.tar.gz
Connecting to downloads.mysql.com (137.254.60.14:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer


なんだよこれ？

root@wandboard:/mnt/share/home/webadm# wget --help
BusyBox v1.32.0 () multi-call binary.

Usage: wget [-c|--continue] [--spider] [-q|--quiet] [-O|--output-document FILE]
[-o|--output-file FILE] [--header 'header: value'] [-Y|--proxy on/off]
[-P DIR] [-S|--server-response] [-U|--user-agent AGENT] [-T SEC] URL...
root@wandboard:/mnt/share/home/webadm#


どうやらyoctoのデフォルトのwgetはbuxybox版だということが原因しているぽい。

これもyoctoのbusyboxのコンフィグレーションをゴニョゴニョとしてwgetを無効にして、別途本物のwgetパッケージをインクルードするようにlocal.confを変更すればいいけど、またBSPビルドし直すのは面倒なので、ソースからビルドすることに。

wgetはGNU softwareなので、busyboxのwgetでもとってこれるので、ビルドしてインストールしたが、busyboxのshellはwgetを内部コマンドとして処理するので、wgetで起動するとbusyboxのwgetになってしまうので、インストールされた/usr/local/bin/wgetとして起動しないとだめだった。

これでmysqlのソースを無事ゲット。

しかしmysqlのビルドにはcmakeが必要だということが判明。

普通はlinux用のオープンソースの大半はconfigureというシェルスクリプトでビルドに依存するライブラリやツールチェインを自動的に調べて最適なビルドスクリプトを生成するのだけど、mysqlはそれをcmakeで行う点が異なる。

cmakeをとってきてビルド＆インストールして、ようやくmysqlのビルドを再開。

[ 67%] Building C object libmysql/CMakeFiles/clientlib.dir/__/sql-common/client_plugin.c.o
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c: In function 'mysql_client_plugin_init':
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c:252:40: error: incompatible type for argument 5 of 'add_plugin'
252 | add_plugin(&mysql, *builtin, 0, 0, 0);
| ^
| |
| int
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c:121:30: note: expected 'va_list' but argument is of type 'int'
121 | int argc, va_list args)
| ~~~~~~~~^~~~
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c: In function 'mysql_client_register_plugin':
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c:310:45: error: incompatible type for argument 5 of 'add_plugin'
310 | plugin= add_plugin(mysql, plugin, 0, 0, 0);
| ^
| |
| int
/mnt/share/home/webadm/mysql-5.5.52/sql-common/client_plugin.c:121:30: note: expected 'va_list' but argument is of type 'int'
121 | int argc, va_list args)
| ~~~~~~~~^~~~
make[2]: *** [libmysql/CMakeFiles/clientlib.dir/build.make:147: libmysql/CMakeFiles/clientlib.dir/__/sql-common/client_plugin.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2401: libmysql/CMakeFiles/clientlib.dir/all] Error 2
make: *** [Makefile:182: all] Error 2

しかしなにやらコンパイルエラーが出た。

どうやら va_listというデータタイプの引数を即値0を指定している行で怒られているらしい。

webで検索すると既知の問題らしく、修正方法が出ていたのでそれを参考に修正。

問題の行のある関数で、va_list args = {0}; を追加して、即値0の引数の代わりに args を渡すように変更するだけ。

再度ビルドを再開すると、まだ伏兵が居た。

[ 97%] Building CXX object client/CMakeFiles/mysql.dir/mysql.cc.o
/mnt/share/home/webadm/mysql-5.5.52/client/mysql.cc: In function 'void build_completion_hash(bool, bool)':
/mnt/share/home/webadm/mysql-5.5.52/client/mysql.cc:2669:37: error: invalid conversion from 'char' to 'char*' [-fpermissive]
2669 | field_names[i][num_fields*2]= '\0';
| ^~~~
| |
| char
make[2]: *** [client/CMakeFiles/mysql.dir/build.make:95: client/CMakeFiles/mysql.dir/mysql.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:3200: client/CMakeFiles/mysql.dir/all] Error 2
make: *** [Makefile:182: all] Error 2

これは field_namesという変数は char *** というデータタイプで、char データタイプへのポインタのポインタのポインタという意味だけど、ポインタは配列の先頭アドレスという解釈と同義なので、charデータタイプへのポインタ配列の配列ということで配列メンバーはポインタであるのに対して、問題の行ではcharデータタイプの即値を代入しているので怒られている感じ。

本来はポインタデータタイプだからcharデータタイプへのアドレスかNULLが適切だけど、このケースではNULLポインタを代入しようとしているので、null文字コード即値の変わりにNULLに変えれば問題なし。

これでビルドが通って、インストールもできた。

次はxoopsを動かすためのphpのビルドとインストール。

/bin/sh /mnt/share/home/webadm/php-4.4.9/libtool --silent --preserve-dup-deps --mode=compile /mnt/share/home/webadm/php-4.4.9/meta_ccld -Imain/ -I/mnt/share/home/webadm/php-4.4.9/main/ -DPHP_ATOM_INC -I/mnt/share/home/webadm/php-4.4.9/include -I/mnt/share/home/webadm/php-4.4.9/main -I/mnt/share/home/webadm/php-4.4.9 -I/mnt/share/home/webadm/php-4.4.9/ext/xml/expat -I/mnt/share/home/webadm/php-4.4.9/TSRM -I/mnt/share/home/webadm/php-4.4.9/Zend -D_REENTRANT -DTHREAD=1 -g -O2 -pthread -DZTS -c main/internal_functions.c -o main/internal_functions.lo
main/internal_functions.c:35:2: error: 'phpext_xml_ptr' undeclared here (not in a function)
35 | phpext_xml_ptr,
| ^~~~~~~~~~~~~~
main/internal_functions.c:36:2: error: 'phpext_tokenizer_ptr' undeclared here (not in a function)
36 | phpext_tokenizer_ptr,
| ^~~~~~~~~~~~~~~~~~~~
main/internal_functions.c:37:2: error: 'phpext_standard_ptr' undeclared here (not in a function)
37 | phpext_standard_ptr,
| ^~~~~~~~~~~~~~~~~~~
main/internal_functions.c:38:2: error: 'phpext_session_ptr' undeclared here (not in a function)
38 | phpext_session_ptr,
| ^~~~~~~~~~~~~~~~~~
main/internal_functions.c:39:2: error: 'phpext_posix_ptr' undeclared here (not in a function)
39 | phpext_posix_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions.c:40:2: error: 'phpext_overload_ptr' undeclared here (not in a function)
40 | phpext_overload_ptr,
| ^~~~~~~~~~~~~~~~~~~
main/internal_functions.c:41:2: error: 'phpext_mysql_ptr' undeclared here (not in a function)
41 | phpext_mysql_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions.c:42:2: error: 'phpext_ctype_ptr' undeclared here (not in a function)
42 | phpext_ctype_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions.c:43:2: error: 'phpext_pcre_ptr' undeclared here (not in a function)
43 | phpext_pcre_ptr,
| ^~~~~~~~~~~~~~~
make: *** [Makefile:710: main/internal_functions.lo] Error 1

ありえないエラーが出る。

どうやらこのソースはwindows用でしかビルド実績が無いぽくて、必要なヘッダファイルがwindows用ソースでしかインクルードされていないのが原因ぽい。

windows用ソースを参考に、当該ヘッダファイルをインクルードする行を追加して解消。

しかし最終的なリンク段階で二重定義が発覚。

/usr/lib/gcc/arm-fslc-linux-gnueabi/10.2.0/../../../../arm-fslc-linux-gnueabi/bin/ld: Zend/zend_ini_scanner.lo:/mnt/share/home/webadm/php-4.4.9/Zend/zend_ini_scanner.c:466: multiple definition of `yytext'; Zend/zend_language_scanner.lo:/mnt/share/home/webadm/php-4.4.9/Zend/zend_language_scanner.c:2638: first defined here
/usr/lib/gcc/arm-fslc-linux-gnueabi/10.2.0/../../../../arm-fslc-linux-gnueabi/bin/ld: ext/mysql/libmysql/my_tempnam.lo: in function `my_tempnam':
/mnt/share/home/webadm/php-4.4.9/ext/mysql/libmysql/my_tempnam.c:115: warning: the use of `tempnam' is dangerous, better use `mkstemp'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: libphp4.la] Error 1

原因は、２つのソースモジュールで、いずれも yytextという大域変数を定義しているため。

片方のソースはextern char *yytext;と char *yytext; 行があるので、後者をextern char *yytext;に変更しもう片方はchar *yytext;を温存する形で解消。

また別のモジュールでヘッダファイルのインクルード漏れが発覚。

/bin/sh /mnt/share/home/webadm/php-4.4.9/libtool --silent --preserve-dup-deps --mode=compile /mnt/share/home/webadm/php-4.4.9/meta_ccld -Imain/ -I/mnt/share/home/webadm/php-4.4.9/main/ -DPHP_ATOM_INC -I/mnt/share/home/webadm/php-4.4.9/include -I/mnt/share/home/webadm/php-4.4.9/main -I/mnt/share/home/webadm/php-4.4.9 -I/mnt/share/home/webadm/php-4.4.9/ext/xml/expat -I/mnt/share/home/webadm/php-4.4.9/TSRM -I/mnt/share/home/webadm/php-4.4.9/Zend -D_REENTRANT -DTHREAD=1 -g -O2 -pthread -DZTS -c main/internal_functions_cli.c -o main/internal_functions_cli.lo
main/internal_functions_cli.c:35:2: error: 'phpext_xml_ptr' undeclared here (not in a function)
35 | phpext_xml_ptr,
| ^~~~~~~~~~~~~~
main/internal_functions_cli.c:36:2: error: 'phpext_tokenizer_ptr' undeclared here (not in a function)
36 | phpext_tokenizer_ptr,
| ^~~~~~~~~~~~~~~~~~~~
main/internal_functions_cli.c:37:2: error: 'phpext_standard_ptr' undeclared here (not in a function)
37 | phpext_standard_ptr,
| ^~~~~~~~~~~~~~~~~~~
main/internal_functions_cli.c:38:2: error: 'phpext_session_ptr' undeclared here (not in a function)
38 | phpext_session_ptr,
| ^~~~~~~~~~~~~~~~~~
main/internal_functions_cli.c:39:2: error: 'phpext_posix_ptr' undeclared here (not in a function)
39 | phpext_posix_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions_cli.c:40:2: error: 'phpext_overload_ptr' undeclared here (not in a function)
40 | phpext_overload_ptr,
| ^~~~~~~~~~~~~~~~~~~
main/internal_functions_cli.c:41:2: error: 'phpext_mysql_ptr' undeclared here (not in a function)
41 | phpext_mysql_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions_cli.c:42:2: error: 'phpext_ctype_ptr' undeclared here (not in a function)
42 | phpext_ctype_ptr,
| ^~~~~~~~~~~~~~~~
main/internal_functions_cli.c:43:2: error: 'phpext_pcre_ptr' undeclared here (not in a function)
43 | phpext_pcre_ptr,
| ^~~~~~~~~~~~~~~
make: *** [Makefile:712: main/internal_functions_cli.lo] Error 1


あり得ないな。これも同様に宣言行があるヘッダファイルを探して、それをインクルードするようにソースを修正して解決。

ようやくビルド＆インストールができた。

root@wandboard:/mnt/share/home/webadm# php --version
PHP 4.4.9 (cli) (built: Jan 2 2021 14:41:13)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

あと、細々としたCGIもビルドしないと。

数式をpngに変換するmathtexを使っているけど、これが一番難儀だな。mathtexはtexとdvipngとかを使用してそれを実現しているので、texとdvipngをソースからビルドしないといけない。

現行のサーバーではubuntuでそれらのパッケージが提供されているので何も考えずにそれをインストールするだけだったけど、今回はソースからビルドする必要がある（texはビルド済みバイナリも配布されているが、流石にARM用バイナリは提供されていない）。

Texのソースアーカイブをとってきて、configureすると怒られる。

引用：

config.status: creating samples/layout/Makefile
Not rebuilding data/rules.mk, assuming prebuilt data in data/in
Spawning Python to generate test/testdata/rules.mk...
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/mnt/share/home/webadm/texlive-20200406-source/libs/icu/icu-src/source/python/icutools/databuilder/__main__.py", line 10, in <module>
import json
ModuleNotFoundError: No module named 'json'
configure: error: Python failed to run; see above error.
make[4]: *** [Makefile:1314: icu-build/Makefile] Error 1
make[4]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/libs/icu'
make[3]: *** [Makefile:719: all-recursive] Error 1
make[3]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/libs/icu'
make[2]: *** [Makefile:906: recurse] Error 1
make[2]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/libs'
make[1]: *** [Makefile:483: all-recursive] Error 1
make[1]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/libs'
make: *** [Makefile:577: all-recursive] Error 1

どうやらyoctoでデフォルトで入っているpython3のmoduleが一切ないぽい。python3本体しか入っていないぽい、あり得ない。

pythonはソースからビルド＆インストールすれば最低限のmoduleは一緒にインストールされるはずなので、ソースからビルドすることに。

root@wandboard:/mnt/share/home/webadm# python3 --version
Python 3.9.1

python3のビルドとインストールができた。

これでtextのconfigureが通り、makeもできた。

しかしインストールで問題発生。

libtool: install: /usr/bin/install -c luajithbtex /usr/local/bin/armv7l-unknown-linux-gnueabihf/luajithbtex
/usr/bin/install: error writing '/usr/local/bin/armv7l-unknown-linux-gnueabihf/luajithbtex': No space left on device
make[4]: *** [Makefile:5162: install-binPROGRAMS] Error 1
make[4]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/texk/web2c'
make[3]: *** [Makefile:17447: install-am] Error 2
make[3]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/texk/web2c'
make[2]: *** [Makefile:16966: install-recursive] Error 1
make[2]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/texk/web2c'
make[1]: *** [Makefile:486: install-recursive] Error 1
make[1]: Leaving directory '/mnt/share/home/webadm/texlive-20200406-source/work/texk'
make: *** [Makefile:577: install-recursive] Error 1
root@wandboard:/mnt/share/home/webadm/texlive-20200406-source/work# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2005316 1988932 0 100% /

yoctoでビルドしたファイルシステムは空き容量が少ないので、ファイルシステムがフルになってしまったのだ。

SDカードなので、ファイルシステムの内容をバックアップして、パーティションを切り直してファイルシステムを作り直すしかない。

もしかしたら16GのSDカードでは足らなくなるかもしれないけど、それは後で考えよう。SDXCカードもたぶんつかえると思うので（試したことないけど）、購入しておこう。


また続きは後日。

んじゃまた。

TeXもCGIとして使用しているmathtexが依存しているので、これが一番大仕事。

良く調べたら、最近のTexliveではARM 32biアーキテクチャのlinux版バイナリも配布しているようなので、必要なのはtexliveインストーラをダウンロードしてビルドして起動するだけだということが判明。

./install-tl --repository https://ftp.kddilabs.jp

デフォルトだと全部インストールになるのはいいのだが、メモリが少ないプラットフォームでは/tmpがtmpfsで空きメモリ分しか利用できないので、最後の最後でパンクして失敗してしまうことが判明。

必要なのはlatexなので（これはtexliveソースをビルドしてインストールしても作られない、debianで提供されているtexlive-2012版だとlatexはpdftexのシンボリックリンクになっているので、2020年版でそのようにしてもmathtexは意図した通り動作しなかった）、schemeを選択するSを入力して、plain texとlatexだけインストールするbasic scheme(b)を選択してインストールするだけだった。

インストールが終わると、ちゃんとtexliveのインストールディレクトリにlatexが出来ていた。

mathtexをビルドして動作確認すると問題なく動作した。

mathtex導入前に使用していたmimetexもビルドして動作を確認。

あと使っているのかどうか謎だけど、全文検索のnamazuも入っていたので、namazuもダウンロードしてビルド。

最新のnamazuはnkfとkakasiに依存しているのでそれらもダウンロードしてビルド＆インストール。

これでバイナリ版のCGIは全部ARM版になった。

あとは、mysqlを起動してhttpサーバーの動作確認。

mysqlはソースからビルド＆インストールしただけだと、コンフィグレーション設定ファイルが無いのでそもそも起動しないことが判明。

現行のサーバーからコピーしてなんとか形を整えて、現行サーバーのデータベース内容をダンプして、wandboard上のmysqlデータベースを作成。mysqladminでユーザーパスワードを設定、これはxoopsがmysqlデータベースを使うのでその設定と同じに設定する必要あり。

あとはhttpサーバーのconfigを現行サーバーからコピーして準備おｋ。

手元のwindows pcのhostファイルを書き換えて、ローカルネットのwww.rainbowseeker.jpのIPアドレスを現行サーバーからwandboardのそれに定義した行に交換。

これでwww.rainbowseeker.jpにpingするとwandboardにpingすることになるのを確認。

httpサーバーもapachectrl startで起動することを確認。

さっそくブラウザでhttps://www.rainbowseeker.jp/xoopsを開いてみると、一応SSLで接続できているがなにやらエラーが。

This page cannot be displayed due to an internal error.

If you are the administrator of this site, please visit the XOOPS Cube official site for assistance.

Error [Xoops]: Unable to connect to database in file class/database/databasefactory.php line 34


どうもphpからmysqlデータベースへの接続が失敗しているぽい。

mysqlコマンド事態では問題なく設定したユーザー名とパスワードで接続できているので、PHP側固有の問題ぽい。

phpをconfigureする際に--with-mysqlを指定していたのだが、どうやらmysqlがインストールされたディレクトリをパラメータ値として指定する方法もあるぽいので試したら、なにやら未定義シンボルが出て怒られた。

/usr/lib/gcc/arm-fslc-linux-gnueabi/10.2.0/../../../../arm-fslc-linux-gnueabi/bin/ld: ext/mysql/php_mysql.lo: in function `zif_mysql_create_db':
/mnt/share/home/webadm/php-4.4.9/ext/mysql/php_mysql.c:1164: undefined reference to `mysql_create_db'
/usr/lib/gcc/arm-fslc-linux-gnueabi/10.2.0/../../../../arm-fslc-linux-gnueabi/bin/ld: ext/mysql/php_mysql.lo: in function `zif_mysql_drop_db':
/mnt/share/home/webadm/php-4.4.9/ext/mysql/php_mysql.c:1206: undefined reference to `mysql_drop_db'
collect2: error: ld returned 1 exit status
make: *** [Makefile:170: sapi/cli/php] Error 1

調べたところ、MYSQLのバージョンによっては未定義とされる内部関数が意図的にコンパイル対象から外されるようになっていることが判明。

無理矢理定義されるようにして解決したという記事もあるので試して見たがだめだった。もっと事態が悪化した。

In file included from /mnt/share/home/webadm/php-4.4.9/main/php.h:38,
from /mnt/share/home/webadm/php-4.4.9/ext/mysql/php_mysql.c:32:
/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:34:23: error: 'zif_mysql_create_db' undeclared here (not in a function); did you mean 'zif_mysql_select_db'?
34 | #define ZEND_FN(name) zif_##name
| ^~~~
/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:38:65: note: in definition of macro 'ZEND_NAMED_FE'
38 | ine ZEND_NAMED_FE(zend_name, name, arg_types) { #zend_name, name, arg_types },
| ^~~~

/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:40:65: note: in expansion of macro 'ZEND_FN'
40 | ine ZEND_FALIAS(name, alias, arg_types) ZEND_NAMED_FE(name, ZEND_FN(alias), arg_types)
| ^~~~~~~

/mnt/share/home/webadm/php-4.4.9/main/php.h:310:21: note: in expansion of macro 'ZEND_FALIAS'
310 | #define PHP_FALIAS ZEND_FALIAS
| ^~~~~~~~~~~
/mnt/share/home/webadm/php-4.4.9/ext/mysql/php_mysql.c:184:2: note: in expansion of macro 'PHP_FALIAS'
184 | PHP_FALIAS(mysql_createdb, mysql_create_db, NULL)
| ^~~~~~~~~~
/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:34:23: error: 'zif_mysql_drop_db' undeclared here (not in a function); did you mean 'zif_mysql_list_dbs'?
34 | #define ZEND_FN(name) zif_##name
| ^~~~
/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:38:65: note: in definition of macro 'ZEND_NAMED_FE'
38 | ine ZEND_NAMED_FE(zend_name, name, arg_types) { #zend_name, name, arg_types },
| ^~~~

/mnt/share/home/webadm/php-4.4.9/Zend/zend_API.h:40:65: note: in expansion of macro 'ZEND_FN'
40 | ine ZEND_FALIAS(name, alias, arg_types) ZEND_NAMED_FE(name, ZEND_FN(alias), arg_types)
| ^~~~~~~

/mnt/share/home/webadm/php-4.4.9/main/php.h:310:21: note: in expansion of macro 'ZEND_FALIAS'
310 | #define PHP_FALIAS ZEND_FALIAS
| ^~~~~~~~~~~
/mnt/share/home/webadm/php-4.4.9/ext/mysql/php_mysql.c:185:2: note: in expansion of macro 'PHP_FALIAS'
185 | PHP_FALIAS(mysql_dropdb, mysql_drop_db, NULL)
| ^~~~~~~~~~
make: *** [Makefile:368: ext/mysql/php_mysql.lo] Error 1

なんだよもう（；´Д｀）

それと毎回configureし直すたびに一部のヘッダファイル抜けソースが再び自動生成されるので修正し直し。

上の自動生成ファイルの問題を調査したら、どうやら本来はちゃんとヘッダファイルをインクルードする行が挿入されるスクリプトになっているが、それを処理する際にmawkというコマンドを使用しているのだが、それが手元のyocto BSPでは入っていないのが敗因。

mawkもダウンロードしてインストールしないと毎回尻ぬぐいの修正などやってられない。

どうやらphp4でのmysqlサポートはデフォルトなのでconfigure時に指定しなくても良いぽい。

今度は修正なしでphpのビルドが通った。

しかし依然としてxoopsのデータベース接続がだめだ。

php自身は問題ないことは、phpinfo.phpで確認。

また機会を改めて原因を調べよう。

んじゃまた。

その後PHP4からMySQL5に接続できない原因を調査したところ、下記の事実が判明。

・PHP4はMySQLのライブラリを使用して接続をしている
・MySQLのライブラリは常にunix domain socketを使用して接続する
・上記のunix domain socketのパスがビルド時のデフォルトで/tmp/mysql.sockに固定されている
・実際のMySQLサーバーは、/etc/mysql/か/etc/配下のiniファイルで設定されたunix domain socketのパスを使用し、それは/var/run/mysqld/mysqld.sockとなっている
・上記の理由でMySQL clientライブラリとサーバーのunix domain socketのパスが異なっていることから絶対に接続できないことが判明

解決方法として、MySQLのclient libraryの使用するunix domain socketのパスを実際にサーバーが使用するパスと同一のものに変更してビルド＆インストールし直すことしかない。

おそらくdebianとかのパッケージではこの問題を独自に解決するパッチが施されてビルドされているため問題が起きないと思われる。

これでブラウザーでページが表示できた、CGIも問題なく機能している。

ただしひとつだけおかしいことがある、それは表示されるページが昨年の7月が最新で、ページレイアウトも昨年末に変更する前のものとなっている点。

データベースは最新のものをdumpしてstoreしたはずだけど、xoopsの方は古いかもしれない。しかし全部データベース駆動になっているはずだが（キャッシュされたレンダリング済みページを覗いて）。

少し調べてみよう。

Windows PC上のMySQL workstationというツールを使って普段はサーバーのデータベースのバックアップをとったりしているので、それを利用して、最新のデータベースをexportして、それを今度はWandboardにimportし、ついでにxoopsのコンテンツフォルダーもコピーして同期をとった結果、まったく同じページが表示されるようになった。

本当にwandboard上のコンテンツを表示しているのか不安になるので、phpinfo.phpで確認。確かにwandboard上のコンテンツだった。



これでWebコンテンツは現行サーバーと同じ内容になったので、残るメールサーバー環境を現行と同じように導入すれば良いことになる。

現行サーバーはメモリが不足しているのでページ表示の応答が返らない時があるけど、wandboardもメモリは足らないけどそうした症状は見られない。

いずれサーバーを移行する予定。

さらにメモリ量の多いARM 64bitボードを調達できれば性能問題も緩和されるはず。

んじゃまた。

その後も現行サーバーは新記事の投稿やアップロードが続くので、wandboardサーバー側もコンテンツの同期を取る必要があるのだが、そのつどコンテンツ丸コピーだと時間がかかるので差分だけコピーすることのできるrsyncを導入しようと計画。

最新のrsyncソースをとってきてconfigure&mail installするだけなはずが、嵌まった（；´Д｀）

まずもってconfigureは一見すると正常に終わって、makeすると膨大なコンパイルエラーが出るという事態から始まった。

root@wandboard:/mnt/share/home/webadm/rsync-3.2.3# make
In file included from ./rounding.c:20:
./rsync.h:604:3: error: #error Could not find a 32-bit integer variable
604 | # error Could not find a 32-bit integer variable
| ^~~~~
./rsync.h:673:2: error: unknown type name 'int32'
673 | int32 size, entries;
| ^~~~~


まずもって、最初の条件コンパイルでのエラー条件に行ってしまっているのが問題。

それもそのはず、configureでビルドするターゲットでの様々な基本データタイプのバイト長を割り出すのが失敗しているぽい。

checking size of int... 0
checking size of long... 0
checking size of long long... 0
checking size of short... 0
checking size of int16_t... 0
checking size of uint16_t... 0
checking size of int32_t... 0
checking size of uint32_t... 0
checking size of int64_t... 0
checking size of off_t... 0
checking size of off64_t... 0
checking size of time_t... 0
checking size of char*... 0

なんだよこれ（；´Д｀）

configureでは各データタイプの長さをそれを値として文字列で出力するCのソースコードを生成してコンパイル実行するのだが、どうやらコンパイルは出来ても実行段階でエラーになるため意図した結果が得られずに、全部サイズ０になっているらしい。

生成しているソースそのものは問題ないのだが、中身をnopにしても実行するとエラーになるので、手に負えないと判断。

webで検索すると問題なくビルドできている方の使っているバージョンが判明したので、少し古い rsync 3.1.3をとってきて試すとまったく問題なくconfigureとmakeができた。

最新版には問題ありなんだな。どのconfigureを使ったオープンソースも似たようなことをしているのにrsyncだけだめだというのはなんか固有の問題があるのだろう。

ということで一件落着。

次はメールだな、そもそもmailコマンドとかfromコマンドとかすら入っていないし（；´Д｀）

そこからだな。

yoctoベースのfsl community linux BSPでも一応webサーバーとしては機能するまで持っていけたけど、メールサーバーを導入しようとした時点で、昔の玄箱の時とは違って簡単にはいきそうもないことが判明。

よくよく調べたら、どうやらARM版のDebianディストリビューションがあるみたいなので、つかえるかどうか試してみることに。

DebianはUbuntuとかもベースにしているくらい定評のある安定したディストリビューションで、なんといっても大抵のオープンソースソフトウェアは既にカスタマイズ＆ビルド＆動作確認済みのパッケージとして、インターネット接続があれば公式サーバーかそのミラーサーバーからコマンド一発で取ってきてインストールできるのが利点。

現行サーバーもx86ノートPCなので少し前のDebianをインストールして使っているけど、もうサポートされていないので新たにパッケージをインストールしようとしてもサーバーにパッケージが置かれていないので、自前でソースからビルドするしかない状態という問題もある。

なのでARM版なら最新のDebianなのでしばらくはサポートされている限りは簡単にパッケージを追加インストールできる。

まずは、手元のWANDBOARDがプラットフォームとしてサポートされているかというのが問題になる。

手元のWANDBOARDはiMX6Soloという一番廉い構成のハードウェアなので心配だったけど、一応WANDBOARDは一本化されていてどれでも対応しているぽい。

本当かどうかはとりあえず、u-boot(bootloader)イメージだけとってきてSDカードに書いて起動するか試せば良い。

DebianのサイトからARM portのリンクを辿ってインストーラーがおかれているページからu-bootの入ったSDカードイメージをダウンロードし、解凍しながらSDカードに書き込む。

SDカードへbootloaderイメージが書き込まれたら、WANDBOARDのSDカードスロットに差し込んで電源を入れるだけ。

起動すると、u-bootが立ち上がり、そのまま自動起動に進むとネットワークからbootしようとするみたいなので、一応対応しているとみてよいだろう。

次に実際にDebianディストリビューションをSDカードに導入できるか試す段階に。

Debainをインストールするには、PCの場合と同じで２通りあって、

(1) DVDにDebianパッケージISOイメージを書き込み、それをUSB DVDドライバに挿入してターゲットに接続し、別途Debianインストーラを起動してDVDからパッケージをインストールする
(2) netboot型のDebian インストーラを起動してインターネット経由でサーバーからパッケージをダウンロードしてインストールする

(1)は予めDVDメディアにDebianパッケージISOイメージをダウンロードして書き込んでおく作業が必要なので面倒だけどインターネットに依存しないので確定時間でインストールが完了できることが利点。

(2)はお手軽だけど、インターネットの速度やサーバーの負荷状況でインストール完了までに長い時間がかかるのと完了までに要する時間が不確定。

とりあえず何度かインストールする必要がある場合は、DVDを使うのが確実だけど、とりあえずお試しなら(2)のネットインストールで十分。

まずは、(2)を試すことに。

netboot用のDebianインストーラはDVDインストールとは同じファイル名で別の場所におかれているので、それをダウンロードして、READMEに書かれている手順を参考にSDカードに書き込むことに。

READMEにはダウンロードしたイメージがgzip圧縮された２つのファイルから構成されるので、それを解凍して連結してひとつのイメージファイルにするように書かれているけど、linux上だと、zcatで２つのファイルを指定して、出力をddの入力にパイプでリダイレクトすればコマンド１行でSDカードに書き込める。

引用：

書き込みが完了したら、それをWANDBOARDの起動用のSDカードスロットに差し込んで電源を入れるだけ。

心配していたけど、その心配は無用だったようで、Debianインストーラが起動して、CUI画面上で見慣れたDebianインストール操作を進めるだけでよかった。

とりあえずお試しで、インストーラを書き込んだ起動用のSDカードにDebianをインストールすることに。

インストーラ自体はメモリ上で動作しているので、SDカードは完全にフリーなので心配ない。

予想通りインターネット経由でのパッケージダウンロードに時間がかかったけど、特に障害もなくインストールが完了。



再起動すると問題なくDebianが起動した。



これで、現行サーバーと同様にセットアップできれば移行する予定。

Debianは確かにパッケージを導入するだけでシステムが構築できるので楽だけど、一方でいろいろなデーモンが起動するのでメモリ食いだということが判明。

webサーバーを立ち上げる前の状態で既に空きメモリが数十MBしかなくなってしまっているので、まだ古いdebianベースのノートPCの方がまし。

そんなこんなで、最新のdebianを採用するのはあきらめてメモリフットプリントの少ないyoctoベースで行くことに決定。

yoctoベースでまだだったのがsambaによるwindows PCとの間のファイル共有（サーバーファイルシステムへのファイルのアップロードとかが便利）だったけど、それも最新のsambaを導入して現行サーバーの設定ファイルをちょこっと変えるだけでいけた。

メールシステムはeximもpostfixも試したけど最新のだと簡単に設定できるような代物ではなくなっていた。

メールは現行サーバーのものを継続使用とするかやめるか（spamしか送られてこないし）。

ということであとはルーターの設定を変更すれば、wandboardベースの新しいサーバーに切り替えが可能。

当面は現行のノートPCサーバーをバックアップとするために、コンテンツ更新した際にはバックアップサーバーにリプリケートするようにするつもり。

最新のsambaをソースからビルドしてインストールするのにひと悶着あったけど、ビルドができたら設定はsmb.confを用意するだけで済んだ。詳しくまた機会を改めて。

んじゃまた。