Zoomって、バージョンアップのお知らせを全くしてこないので、起動時に勝手にアップデートされていると思っていたんですが、全くそんなことはなかったですね。ずっと古いバージョンの5.3.1(2020/09/28リリース)のまま使っていました。
手動でアップデートしたところ、無事に最新版の5.4.9になりました。4ヶ月で大分数字が変わりましたね。
比較的新しいアプリの割にアップデートは保守的ですね?不思議な設計だな……??
Facebookのコメントで「ミーティングの後」にバージョンアップのお知らせが出ることを教えてもらいました。
ミーティング前にバージョンアップすると遅刻する可能性大なので、ミーティング終了後に表示するのは良いアイデアですね。でも残念ながら、見たことないんだよな……。うちのZoomは何か変なんだろうか??
メモ: 技術系?の話はFacebookから転記しておくことにした。加筆。
久しぶりにPlayStation Vitaを起動したところ、ネットワークに繋げる系アプリがほぼ全滅していました。
プラットフォーム依存のゲーム機は、本体が元気でもサードパーティの撤退やサービス終了に伴って、勝手にポンコツになってしまい悲しいです。結構高かったのに……。
ソニー製
サードパーティ製
PlayStation Storeを見ると「アプリケーション」はたった14個、サードパーティ製のアプリは1つ(ROBOTICS; NOTES ELITE AR)だけです。PS Vitaは既に9年経過(2011年12月発売)しており、ぶっちゃけソニーすらもVitaを見放している節があり、もう完全にオワコンです。
それなりに大きなプラットフォームの終焉を間近で見たのは貴重な体験、とはいえ、買った人は何も嬉しくないよね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。多少修正。
年末(2020年12月20日の日記参照)に、1月はSUPER VALUE 21 Jより安いチケットがVALUE 3で出ると予想しましたが、外れましたね。1/30の羽田→札幌便を見ると、最安はVALUE 3 Jで年末からほとんど変わっていません。
いやまあ、SUPER VALUE 21とVALUE 3の値段がほとんど変わらない時点で、かなり異常事態なんですけど……。
なんと全25便中、半分近い11便が欠航しています。飛ばす回数を自体を減らし、客単価の維持とおそらく各便ごとの黒字を確保しているのでしょう。単発で黒字が出たとしても、確実に収益にはダメージがありますよね。安いイメージが付いてしまうより良いのかなあ?
燃料費などは減便で節約できても、飛行機はリースなので飛んでも飛ばなくてもお金が掛かります。飛ばせるならいくらでも飛ばしたいでしょう。
早いところCOVID-19には収束してもらって、気軽に旅行や帰省できる日が来てほしいですね。ANAは今かなり苦しいでしょうけど、日本の翼を担う会社として何とか踏みとどまってほしいところ……。
目次: Zephyr
前回はツールチェーンビルドの仕組みを確認するためCrosstool-NGに立ち返り、正常動作するバイナリが作成できましたが、手順が多くて面倒でした。実はZephyr SDKだけでパッチを当てる仕組みがあります。
Crosstool-NGのパッチ当ては前回紹介したpackagesの下にあるパッチを使うのが基本ですが、他の場所(ローカルパッチディレクトリ)も追加できます。CT_LOCAL_PATCH_DIRというコンフィグに設定されます。
$ ./ct-ng menuconfig Paths and misc options ---> () Local patch directory
Crosstool-NGのパッチ当て処理を見るとパッチを当てる順番を選択できるようになっています。
# crosstool-ng/scripts/functions
CT_DoExtractPatch()
{
...
CT_DoLog EXTRA "Patching ${basename}"
CT_DoExecLog ALL touch "${src_dir}/.${basename}.patching"
bundled_patch_dir="${CT_LIB_DIR}/packages/${pkg_dir}"
bundled_common_patch_dir="${CT_LIB_DIR}/packages/${pkg_name}"
local_patch_dir="${CT_LOCAL_PATCH_DIR}/${pkg_dir}" #★★ローカルパッチディレクトリ
#★ディレクトリ名を列挙
#★patch_orderは "bundled, local" になっていた、CT_PATCH_ORDERで決まるようだ
case "${patch_order}" in
bundled) patch_dirs=("${bundled_patch_dir}" "${bundled_common_patch_dir}");;
local) patch_dirs=("${local_patch_dir}");;
bundled,local) patch_dirs=("${bundled_patch_dir}" "${bundled_common_patch_dir}" "${local_patch_dir}");;
local,bundled) patch_dirs=("${local_patch_dir}" "${bundled_patch_dir}" "${bundled_common_patch_dir}");;
none) patch_dirs=;;
esac
CT_Pushd "${src_dir}/${basename}"
for d in "${patch_dirs[@]}"; do #★ディレクトリを順に辿る
CT_DoLog DEBUG "Looking for patches in '${d}'..."
if [ -n "${d}" -a -d "${d}" ]; then
for p in "${d}"/*.patch; do
if [ -f "${p}" ]; then
CT_DoExecLog ALL ${patch} --no-backup-if-mismatch -g0 -F1 -p1 -f -i "${p}"
fi
done
fi
done
...
今回のケースではpatch_orderは "bundled, local" になっていたので、packages -> ローカルパッチの順にパッチを当てるようです。patch_orderの決め方は深追いしていませんが、CT_PATCH_ORDERで決まるようです。
Zephyr SDKの設定ファイルを見るとローカルパッチディレクトリは下記のようになっています。
# configs/riscv64.config ... CT_LOCAL_PATCH_DIR="${CT_TOP_DIR}/../../patches"
CT_TOP_DIRとは何でしょう?ビルドログを追うとCT_TOP_DIR=/.../sdk-ng/build/build_riscv64でした。すなわちsdk-ng/patchesがローカルパッチディレクトリです。ディレクトリには既に6つほどのパッチが置かれています。
$ ls patches/gdb/9.2 0001-gdb-remote-make-tid-pid-type-long-in-write_ptid.patch 0002-gdb-Add-fixes-for-stdint-and-remote-debug-on-xtensa.patch 0003-gdb-xtensa-don-t-error-out-when-registers-cannot-be-.patch 0004-gdb-xtensa-use-remote-target-register-numer.patch 0005-gdb-arch-to-tell-whether-it-supports-g-packets.patch 0006-gdb-xtensa-support-disabling-use-of-g-packet.patch
ここにPython 3.9で落ちる問題を修正するパッチを追加します。
$ cd sdk-ng $ cat > patches/gdb/9.2/0007-gdb-fix-python3.9.patch (パッチをコピペする) $ ./go.sh riscv64
ビルドログはbuild/build_riscv64/build.logに作られます。
# Crosstool-NGの持っているパッチを当てているログ [DEBUG] Looking for patches in 'sdk-ng/share/crosstool-ng/packages/gdb/9.2'... [DEBUG] ==> Executing: '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/share/crosstool-ng/packages/gdb/9.2/0000-musl_fix.patch' [ALL ] patching file gdb/linux-nat.c [ALL ] patching file gdb/stopcode.h [DEBUG] ==> Return status 0 ... # Zephyr SDKのローカルパッチを当てているログ [DEBUG] Looking for patches in 'sdk-ng/share/crosstool-ng/packages/gdb'... [DEBUG] Looking for patches in 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2'... [DEBUG] ==> Executing: '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2/0001-gdb-remote-make-tid-pid-type-long-in-write_ptid.patch' [ALL ] patching file gdb/remote.c [DEBUG] ==> Return status 0 ... # 追加したパッチを当てているログ [DEBUG] ==> Executing: '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2/0007-gdb-fix-python3.9.patch' [ALL ] patching file gdb/python/python.c [ALL ] Hunk #1 succeeded at 234 (offset -4 lines). [ALL ] Hunk #2 succeeded at 271 (offset -4 lines). [ALL ] Hunk #3 succeeded at 952 (offset -19 lines). [ALL ] Hunk #4 succeeded at 1552 (offset -68 lines). [ALL ] Hunk #5 succeeded at 1720 (offset -70 lines). [ALL ] patch unexpectedly ends in middle of line [DEBUG] ==> Return status 0
ちなみにZephyr SDKのビルド後、GDBのソースコードはsdk-ng/build/build_riscv64/.build/riscv64-zephyr-elf/src/gdbに展開されます。パッチが正常に当たったか確認するなら、このソースコードを見れば確実でしょう。
SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。
$ cd build/output/riscv64-zephyr-elf/bin $ ./riscv64-zephyr-elf-gdb --version GNU gdb (crosstool-NG 1.24.0.212_d7da3a9) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
動きました、良かった良かった。build/output下に生成されたriscv64-zephyr-elfディレクトリをZephyr SDKのインストールディレクトリ下にある同名のディレクトリと差し替えれば、GDBが動くはずです。
< | 2021 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | - | - | - | - | - | - |
合計:
本日: