The Man Who Fell From The Wrong Side Of The Sky:2009年5月9日分

[最新版] [一覧] [前月] [今月] [翌月]

2009/5/9(Sat)

今日

@

scim-helper-managerのcoreダンプをなんとかしたいネタ。
わたしの もうちょい先のエントリを読んで頂くと良いかと。
ここはltdl.cppを書き換えるのではなく、Makefileで-lpthreadすることで
scim-helper-managerにlibpthreadをリンクするのが正しい解決方法だと思われます。
pkgsrcでは我らがobacheさんが 対策済ですな。

なぜこういうことが発生するかっちゅーと一部のlibcの関数は排他制御に
mutexやrwlockを利用してるからですな、 このへんのエントリを参照。

scim-helper-managerはデフォルトでは非threadedアプリなのでlibpthreadをリンクしてません。
なので__isthreadedは0ですのでlibc内のロックは回避されます、当然mutexなどは初期化されていません。

しかしdlopen(3)でthread-awareでlibpthreadをリンクしている共有ライブラリを
読み込んだタイミングで__isthreadedが1になってしまいます。
つまりこれ以降はlibc内ロックは常に呼ばれる状態になるわけです。
にもかかわらずmutexなどは初期化されてないとくりゃ、core吐いて死ぬのは当然ですがな。

NetBSDの場合、CのアプリがC++の共有ライブラリをdlopen(3)すると
crt*の問題でクラッシュするちゅう問題も別途ありますな、 これ

他にもscimはg++が3以降の場合、default constructorとかchar_traitsの使い方が
怪しすぎていろいろ動作がおかしいのですが、メンテされとらんようですし
個人的には kinput2uimの使用をお勧めしておきます。

@

フィルムスキャナ新製品、おいらのNikon Coolscan 5ED中古相場脂肪www
あー無理してでも5000EDか9000ED買っときゃヨカタかな。

@

FreeBSD SoC、Table1のCitrus implementation status、NTF(中身が大変不正確)過ぎる。
かなりムカッ腹立ってきたので、そのうち変換表の出典とか正誤表書いてやるかね。
これGNU libiconvの変換表と比較してinaccurate(=杜撰)とかいってるレベルな希ガス。
まぁFreeBSDとか全く興味ないけど、Citrusがアレだと思われたら堪らんわ。

freebsd-hackers(なぜfreebsd-i18nじゃないのだろう…)の方で我らがjoerg氏が頑張ってるなw

ポカーン

Citrus is based on UCS-4 as an internal encoding, just like
the another BSD-licensed iconv library. This is a barrier to support
encodings that aren't supported by UCS-4.

お前は何をいっているんだ.jpg 略

前も書いたけど、Citrusは

俺は厳しいが公平だ 人種差別は許さん ISO-2022, UnicodeをCSIは見下さない すべて─── 平等に価値が無い!

なんだがね。

src/share/i18n/csmapperにある変換表がみんなUnicode vs 他の文字コードなのはUnicode自体の罪。
他の文字コードとの変換にテーブルを使わざるを得ない欠陥品(=ほほえみデブ)であることの証明だよな。
CitrusはUnicodeなんぞに依存して実装されてません、現にeucJP <-> Shift_JISのよに同じ文字集合なら
いちいちUCS4に変換してテーブル検索とか頭の悪いことをやってないのでGNU libiconvとかより速度有利 *1


*1:ただしwchar_tをcsid/indexに分解するコストがあるのでqkcなんかよりは遅いけど。
でもこれもplugin書けば勝てる可能性あり。



[ホームへ] [ページトップへ]