「OpenBSD 3.8 予約開始と新曲」記事へのコメント

LC_CTYPE サポート

[Anonymous Coward]

Citrus Project [chuo-u.ac.jp]の成果が取り込まれたんでしょうか？

Re:LC_CTYPE サポート

[Anonymous Coward]

Add isw* widechar classification functions to libc from citrus. [openbsd.org] だそうです。

Re:LC_CTYPE サポート

[Anonymous Coward]

＞ なお 3.8 には、日本人に嬉しい LC_CTYPE サポートが付いています

cvsweb経由で見る限り src/lib/libc/citrus/modules に
i18n_modules関係がimportされていないんで、
EUC-JP他のmultibyte localeは使えないようですが？

Re:LC_CTYPE サポート

[deleted user (19654)]

仕組みはよく知らないのですが、snapshot を使ってみたら
ja_JP.eucJP.src というファイルを NetBSD かどこかから
もらってきて mklocale すれば使えているようです(*)。
uim-fep がパッチなしでビルドできたので嬉しくて、つい
LC_CTYPE サポート OK って書いちゃいました。

でも packages から持ってきた vim の挙動がおかしいから
mblen とかは実際、変なのかもしれません。

これから i18n_modules というものについて調べてみます。
それを使えば vim が直る、というのなら嬉しいなあ。

(*) undeadly.org では locale 系に反対する意見も多数あったので、
デフォルトでは /usr/share/locale/ja_JP.eucJP/LC_CTYPE とかの
ファイルは付いてこないのかもしれませんね。

Re:LC_CTYPE サポート

[Anonymous Coward]

それは話の順序が違うような。

1. multibyte localeをサポートするには
i18n_module(/usr/lib/i18n/lib${ENCODING}.so)が必要
2. それらがソースツリーにない現状では依存する
ja_JP.eucJPその他のlocale databaseはインストールされるべきではない

ってことでしょ？
undeadlyあたりでPOSIX localeイラネ派が騒いでるから
入れないってことでは全くないと思いますが。

i18n_moduleがなぜソースツリーに入らないかは
議論が表に出てこないので推測ですが、前のACの仰るとおり
おそらくdlopen(3)系の関数に依存したくないからでしょうか。
認証周りもデファクトのPAMでなくBSD Aut

Re:LC_CTYPE サポート

[Anonymous Coward]

dlopen() を嫌って static link するという選択をしたはずですが、違ったかな。