Not only is the Internet dead, it's starting to smell really bad.:2009年09月下旬

2009/09/21(Mon)

今日

@

pkgsrc方面詳しくないんですが、今NetBSDのbaseに含まれてるgettext-toolが0.14.4と古いせいで
0.15から導入された*.poのmsgctxtキーワードを理解しないせいでbuildが上手くいかない問題
ってどれくらい深刻なんでそ。

それとgettextを最新の0.17にするとした場合、GPL3ってまじぇまじぇしていいんだっけ?

2009/09/22(Tue)

今日

このスレで思い出したけど、 Desktop Projectってどうなったんでしょ。

ちなみに >>9、上から

ちう感じ。

@

昔撮ったビデオのデジ化にTomson Canopusの ADVC-55を買ってみたのだが
この機種はノイズリダクションがないので、以前から持ってて全然使ってなかった
MTVX2005でmpeg2キャプチャしたほうがマシだったちゅーメシマズ状態。
ソフトウェアでノイズリダクションって何使うのがいいのだろ。

@

tech-userlevelでfold(1)のmanが正しくない話で思い出したけど
fold(1)で今stateful encoding扱えない件について、ちゃんとBUGSに書いとかんとな。

2009/09/23(Wed)

今日

@

先日触れたgettext-tool問題とGPL3のネタについて obacheさんに完璧超人的まとめしていただいた
おかげで完全に状況を把握しますた、いつもありがとうございます(ペコリ

つまり当面サボれるということか(ぉい

2009/09/25(Fri)

今日

@

lib/42124、こんな パッチで多分おk。

元々multi-locale実装のためにスクラッチに近い状態から書いてたコード
(たうぜんテスト不足)を使いまわしたので、動いてるものを壊す典型になってしもうたな。
ま、しゃぁない(開き直り)。

後でcommitする。

2009/09/26(Sat)

[NetBSD] gettext-tool

@

ゲゲゲgettext ひとりーではー

@

そもそもgettextの*.moのフォーマットはMIかつOS非依存なので
いちいちmsgfmtで(1)*.poからビルドさせるのも時間の無駄なんだよな。
だったらふつーにsrc tarballにコンパイル済*.moを同梱しとけという。

つまりはgettext-toolがインストールされていることを期待する
configure scriptは[お察しください]ということです。

しかしGNU gettextは過去に何度か互換性壊してやがるのでOSにインストールされてる
libintlのバージョンによっては読めない*.moになるという自爆テロ問題があるんだよな。

たぶんそれがあるから*.poだけ用意してmake時に*.moをコンパイルしてんじゃないかと推測。
でもOSにインストールされてるgettext-toolとlibintlってふつー同じバージョンなので意味 JAXANASA。

そもそも^2 gettextize(1)はOSにlibintlが存在しない場合を考慮して
intlというディレクトリ以下にlibintlをごっそりコピーしてきてるので
こいつをちょっと弄ってOSのlibintlのバージョンがsrc tarballに同梱の
*.moのバージョンと互換性がない場合も同様にbuiltinにすればいいだけだと思うんだが。

まー時代はcatgets(3)だよねー(さすがにそれはない)。

@

あとgettext-0.17ってglib2にlibxmlにlibcrocoまで自前で抱え込んでるんだが
どうしてこうなった、やっぱりBSDL gettext-toolかなぁ。

続 lib/42124

@

これの続き、LANG=jaの場合、LC_MESSAGESだけsetlocaleに成功してるのは
NetBSD-4.0までLC_MESSAGESの実装がないけれどもcatgets(3)は存在したので
ディレクトリがあれば、常に成功するkludgeが入ってたからでんな、この 差分参照。

ちうことでlibcは送ったpatchでもおkなんだけど、LANG=jaをLANG=ja_JP.eucJPへの
aliasとかsymlinkにする必要があるってやつ。

gettext自体はLC_MESSAGES=ja_JP.eucJPだったらそこからja_JP -> jaを探すという処理が
入ってたはずなので、aliasにしなくても本来は問題なかったはず。

2009/09/27(Sun)

今日

@

libintlまじぇまじぇネタ
いちおlibiconvとかgettextはこの手のトラブルを避ける目的として
関数名にprefixつけるようヘッダで細工してたり、*.moとかlocale.aliasの読込先を
変更する為のrelocation prefix APIが準備されてたりはします。
ただしこれ現状はlibcとの競合を避けるための最低限の実装でしかないので以下略。

それとこれlibintlだけの話じゃなくて、xmalloc.cとかのwrapper関数も以下同文。

ELF symbol versioningのように、リンクエディタがどのライブラリのシンボルであるかの
アノテーション情報も埋め込み、それをリンクローダが実行時に参照して解決するような
仕掛けが無いことには根本的解決は難しいような希ガス。