アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
LC_CTYPE サポート (スコア:0)
Re:LC_CTYPE サポート (スコア:0)
Re:LC_CTYPE サポート (スコア:1, 参考になる)
cvsweb経由で見る限り src/lib/libc/citrus/modules に
i18n_modules関係がimportされていないんで、
EUC-JP他のmultibyte localeは使えないようですが?
Re:LC_CTYPE サポート (スコア:2, 参考になる)
ja_JP.eucJP.src というファイルを NetBSD かどこかから
もらってきて mklocale すれば使えているようです(*)。
uim-fep がパッチなしでビルドできたので嬉しくて、つい
LC_CTYPE サポート OK って書いちゃいました。
でも packages から持ってきた vim の挙動がおかしいから
mblen とかは実際、変なのかもしれません。
これから i18n_modules というものについて調べてみます。
それを使えば
Re:LC_CTYPE サポート (スコア:0)
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 Authを使うくらいだし。
loadable module化せずにFreeBSDと同様libcに
multibyte locale周りを全部突っ込んで回避しても
いいんでしょうが、/bin /sbinがstatic linkedなOpenBSDでは
binary sizeが大きくなるのが困りもの。
LD_PRELOAD=/usr/lib/libxpg4.so
ってわけにはdlopen(3)以上にいかないしねぇ…