蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2005年11月23日分

2005/11/23(Wed)

OpenBSD/Citrus

@20051123版

/distfiles/citrus/OpenBSD/HEAD-citrus-20051123.tar.bz2
諸々の事情↓によりABI崩れてます、ユーザランドの再コンパイルが必須です。

  • 最近のld.soはメンバ追加でサイズが大きくなった構造体への参照があると再コンパイルを促す警告を出す
    (さすがパラノイア、これしきの変更でlibcのバージョン上げてもなんともないぜ)ので、
    struct localeconv(see locale.h)とstruct _MonetaryLocale(see sys/localedef.h)に対する変更を
    バックアウトせざるをえなかった
  • FileRune*構造体にあったFreeBSD互換目的のpaddingが、OpenBSD本家merge時に消されてしまった
  • MB_LEN_MAX 1 -> 32でABIが崩れる件、以前はNetBSDにならって__RENAMEマクロで回避するrename.patchを
    用意してたけど今回廃止。
    あれってABIの新旧をsetlocale(3)の中の人が誰か?で判断してるのだけども
    1. 古いlibcでbuildされたshared library
      内部でMB_LEN_MAX=1のサイズの領域を静的に確保した上でwcrtomb(3)を呼出
    2. MB_LEN_MAX=32の新しいlibc.so
    3. 1と2をlinkするbinary、setlocale(3)を呼び出すのはこいつ
    とかやっちまった場合
    (1.のcompile時のMB_LEN_MAX) < (2.で使われる__mb_len_max_runtime)
    
    となり、カナリア踏んでSEGVるかどっか壊すので100%有効な対策ではない。
    (renameすべきはmbrtowc/wcrtombファミリーだった)

以前のpatchをあてた環境からのアップデートであれば、本家でlibcのバージョンが上がったので影響はないと思う。
むしろrename.patchを廃止したためにpatchなしのOpenBSDとのbinary compatibilityがなくなってしまったのよね…
つか、本家で先日MB_CUR_MAXを定数から変数に変更した時に、同時にMB_LEN_MAX=32にしといてくれれば、
今回はlibcの入れ替えだけmultibyte localeが使えたはずなんだがね…なんか手順ぐちゃぐちゃ。