昔の最近の出来事(2000.07)

2000/7/31

なにげに 「PowerPC Microprocessor Family: The Programming Environments For 32-Bit Microprocessors」 (いわゆるPPCプログラミング環境マニュアル)を眺めていると、ppcsimでの load/storeのrA=0,rA=rBの扱いが間違っている事が発覚(^^;。まぁ、いまいち 不明な点だったので、プログラムのソースにも怪しげなコメントが残っている 訳ですが(^^;。要は、アドレス更新ロード/ストア時(lhauxとか)にrAに0を指定 した場合に、特殊な振る舞いを行う訳ですが、この処理がいい加減になってい ます。コンパイラの吐く命令列には含まれていない様なので、今まで動作して いるプログラムについては、それでOKな訳ですが。ううむ(^^;

彩 for Win Ver0.0.04を試した所、DLLなっしんぐなエラーが出て立ち上がらず。 報告しておいた所、午前中に修正版(Ver0.0.05)がっ(^^;; 帰って試した所、無事 立ち上がりました。

拾えなかったbzip2-1.0.1ですが、国外のftpミラーサイトに置いてありました。 で、拾ってみてコンパイル。gzipと同じ様な関数が足りなかったので、gzipで 使ったスタブ関数をそのまま使ってリンク。OKそう。
で、実行。エラーがでます。所が、プログラムの中に仕込まれたエラー メッセージで、IOエラーの様ですが、どこでエラーしているのやらさっぱり 判りません(^^;。 -vvvv でバーボーズレベルを上げてみるも何も変わらず(本当に効いている のかも不明)。しかたないので、printf()デバッグ(^^;(＜だせぇ)。
オーナーシップを変更する部分でスタブ関数が必ずエラーを返す様になって いたのが原因。そこをコメントアウトするも、今度は先でメモリ不足を 告げるエラーが。むぅ。うまくいかんのぅ。

彩がまたバージョンアップしていました。今度のはベンダータブレットドライバ に対応したとの事。これでUSBタブレットユーザも使える様になるのかしら？

他、謎作業とか。

死んだように寝てしまった(-_-;;;; まずいなぁ.....

なにげにうぇぶぐるしてみると 彩 for Winがバージョンアップ してましたよ！ スポイトにバグがあったとの事。..........あれ？....... 前バージョンのreadmeを読んでみると(読んでなかったんかい！！)、スポイトも スクラッチパットも使えると書いてありますよ！！！ はわわ、もう一度前 バージョンを使ってみると、使えるし！ あぁ、 確かに使えなかったハズなのに！ 再現を試みるも、一度使えると判ると、 どうやっても使えてしまいます(ありがち)。という事で、 忘れてしまおう (っておぃ！＃)
つー訳で早速。


先日作ったコンバータ＋cjpegでセーブを行ってみました。
キャラが変わっている様な気がしますが、いつもの事ですから 。
今回はスポイトバグフィックスの他に、PageUp/PageDownで表示の拡大縮小ができ る様になっています(他、カーソルキーでスクロール、Homeで画像中心アジャスト)。 これ、実は線画のリファインを行うには非常に重要な機能です。そんな訳で、今まで のお試し描きに比べると線が少々整理されています(^^;。 キー位置的には、本物のPageキーやカーソルを使うよりは、NumLock OFFでテンキー を使うのが良い様に私は思いました。
マスクを除いた基本的な機能はX68k版とほぼ同等になってきた様に思います。 私の場合、X68k版でそこそこ勝手を知っているので、特に悩む事は無いのですが、 今まで彩を使った事の無い方々がどのような反応を示すのかに、非常に興味 ありありです。

gzipコンパイルの続き。
取りあえず、足りない関数を空関数で代用してリンク。成功(^^)。そして実行。 取りあえず動いたっぽいのですが、Cygwinネイティブのgzipで gzip -t foo.gz してみた所、エラーしてしまいました(T.T)。展開の方を試してみましたが、こちらの 方はOKそう。うーむ。
コンパイルオプションを変えてみるも変わらず。..........もしやbssセクションクリア していない問題？ということで、bssセクションをクリアしたファイルをppcsimでちょこっと 作って実行。OKでしたよ(^^)v。
bssセクションは、SVR4では0クリアしてロードしてくれるものらしいので、それを期待 する事は間違いではない様です。うむ、いかんせん実行ファイルローダがいいかげんなの で、その辺が問題になりますなぁ。

やっちまった。
*.saiファイルのppmコンバータを作ってみました。今回のSAIファイルは、 無効ブロックはセーブされない構造だったり、ARGBの関係が変わっていたりと なかなか。無効ブロックを用意する構造の方が、圧縮とかもしやすそうです。 ARGBの関係もα合成するにはこちらの方がずっと良い感じですね(って誰に言って るんだ？)。サイズの部分がビッグエンディアンになっているのは X68k時代の名残でしょうか？(^^;

彩 for Winがバージョンアップ されてましたよ。変わっていない様に見えるけど凄く変わったらしいので、 早速ダウンロードしましたとも。!!!!!!!!!!!! かなりレベルアップしてますよっ！ ファイルのload/saveができる様になっているし、消しゴムもちゃんとついたので、 多い日も安心です。そんな訳で早速。



今回の彩の見所は、レイヤー操作(と言っても今の所、表示のON/OFFのみ)、透明保護 でしょうか。レイヤー表示のON/OFFは えらく しゃきしゃき行われるので、いい感じ です。透明保護はX68k版でもありましたが、使いようによってはなかなか。Win版で は透明保護の作りをアレしてナニするという構想もあるらしいです(＜って何やら さっぱり判りません)。スクラッチパッドが表示されていたので、使えるかと思ったら 飾りだったのは残念。スポイトも今の所無いので、基本色だけで塗る必要があります。 褐色にしようと思ったけど、そうでないのはその為です(＜本当か？)。あと、 レイヤーの上下関係がX68kのそれと逆になっています(==Photoshopとかと同じ)
いまの所 *.saiファイルにしかセーブできませんので、Windowsのスクリーンキャプ チャ機能でセーブしました。手が空けば、捨てプログラムでコンバータとか作って みようかと思ったのですが、この辺は色々と加減があると思いますので、 そういう事で。

すんごく眠くて、速攻で爆睡。

なにげにシミュで動作させる為のlsもどきを作ってみる事にしました。fileutils のlsはリンクができないので少し挫けたというのは気のせいです(^^;(＜そうか？)
超基本機能版(ソートもされていませんよ)ですができました。 つーか、ディレクトリ ストリームの使い方の練習プログラムですな(笑)。

bzip2でもコンパイルしてみようかと思い、アーカイブを探してみると、 1.0.1とかいう最新版が先月出ていた様です。ところが、ダウンロードを 試みるも、ページを開くのもままならない重さです！。よく思い出してみると、 以前にも同じ理由でダウンロードを断念したのを思い出しましたよ(^^; ミラーサイトを探してみるも、1.0.1は見つからず。ぐう。
しかたないので、gzipをコンパイルしてみることにしました。いくつか関数が 足りなくてリンクで失敗。うむむぅ。

リンクページの変更を試みる。途中で力つきる(ぉぃ;

体調がいまいちなので洗濯したり掃除したりして過ごしてみました。下手に エアコンで温度調節すると体調回復がいまいちなので(経験則)、窓を開ける だけにしてましたが、外が涼しいくらいでしたよ(^^;

「特命リサーチ200x」を久しぶりに観たのですが、デジタル記憶媒体の自然 劣化の話をしてました。CDの劣化については10年前に、早いもので7年で 腐食が始まるという話を聞いた事があったので、無限に使えるなんて思って いなかったのですが、一般的には無限に使えるものだと思われている(た?)もの らしいですね。
他にも停電でコンピュータがおっこちて大量のデータがすっとんだ話だとか、 古いハードで書かれた記録媒体がハードが無くなって取り出せなくなって しまったとか色々。前者なんかは、Winとかで使っていれば日常茶飯事みたいだし、 後者は、今まで取り出す事なく置かれていたのだから、きっと将来も取り出す 事は無いという気がします。ジョークで、「100年後の未来に過去の記録を発掘 しようとしたが、100年前のデジタル記憶媒体は復元不能なほどに劣化し、 なんとか復元可能な状態で残っていたのは紙に残った記録であった。しかし、 全くそのまま残っていたのは石版に彫られた文字だった。」はステキすぎだと 思いました。

大抵、一晩寝ればそれなりに元気になるのですが、全く回復する気配無し。 久々の大風邪の模様。動けないので寝るだけ。

夜になってそれとなく回復した模様。ふぅ、死ぬかと思った。

で、fileutilsの続き(＜バカです)。
opendir()をシステムコールに格上げする事を考えました。問題となる点は、 opendir()内でmalloc()使用して、ディレクトリストリームの為のメモリを動的に 確保して、そのポインタを戻り値としている点。単純に引数だけを渡して、 エミュレーションしたのでは、その戻り値はシミュレータメモリではなく、 シミュレータ内のメモリを指してしまう事になるので、良くありません。そこで、 _opendir(const char *name, DIR *dirp)というシステムコールを用意する事 にして、それをopendir()でラッピングし、_opendir()のdirpはopendir()内で malloc()を使用してメモリ割り当てを行うという事にしました。こうなると、 ディレクトリストリームを引数とするものは全てシステムコールに格上げする 必要があります(^^;。で、ライブラリとシミュを修正して実行。 動きません(＜いつも通りです)。
readdir()が動いていない様子。色々網をかけて調べてゆくと、シミュの間違いと コンパイル時のヘッダがまずかったのとライブラリコンパイル時のヘッダがまず かった事の複合で動かなかった模様。シミュの間違いは、opendir()をエミュ レートした後、シミュレータメモリにその戻り値をコピーするので、closedir() してもよかろうと思ったのが間違い。実際にはDIRのメンバーであるdirent構造体 がディレクトリ内のファイル数だけ存在していて、これはどこか見えない所で ディレクトリストリームが管理しているという仕掛け。従って、closedir()して しまった途端に、readdir()をエミュレートする事はできなくなってしまいます。 これを回避する為に、_opendir()に渡すDIR *dirpのアドレスから、エミュレー ション内で管理するファイルストリームのDIRポインタに一度変換し、readdir()は 変換後のファイルストリームを使用する事にしました。これにより、_opendir() に渡す*dirpの実体はどうでも良くなるのですが(^^;、まぁ、良しとしましょう。 readdir()の方もopendir()と同じく、戻り値がポインタを返す方式なのですが、 何も考えずにエミュレートした戻り値を返していたので、シミュレータメモリに 値をコピーする様にしました。ここら辺、本当はopendir()をエミュレートした 時に、direntメンバーを全て読み取ってopendir()でどうにかしてシミュレータ メモリに持ち込むのが正しいと思われるのですが、readdir()などのソースを用意する 必要が出てくる為、当面はこの方法で行くという事で。
ヘッダの方は、まぁ、いつもの奴で、無理矢理コンパイルを通す為に用意した sys/dirent.hとCygwinのsys/dirent.hが合っていない所があって、メンバーの サイズが違ったりという、以前POV-Rayでやった奴と同じです( __)/□。
で、修正しまくり、どうにか動きました(^^;v 。しかし、 Cygwinネイティブのduと結果が異なります(^^;が、ブロックサイズの定義が異なる らしく、その分を考慮に入れると(あと、stat()で取得したst_sizeが正しい 事も確認した上で)正しそう。ただ、du -b というバイト単位で容量を表示する オプションがあるのですが、これも合わない(^^;。見てみると、ブロックサイズで 割った後に、またブロックサイズを掛けてバイトサイズだ としている様です。 Cygwinネイティブのduではその辺どうしているのか調べてみておく必要がある かも。

お仕事(本物)中にも風邪がどんどん進行。帰ったら全く動けなくなって しまいました(x_x)。

海の日だってのに休出(T-T)。油断して腹出して寝てたら、またまた風邪 気味な模様(*_*)。

Another HTML-lint gatewayというサイトでHTMLの文法をチェックして くれるという事で、 へっぽこのトップページ をチェックしてみました。
結果、 「このHTMLは -467点です。」ですって。 ぎゃはは、面白いので直さずに ほっておく事にしました。

fileutilsの続き。
duの実行で標準出力が狂ってしまうのは、stdoutをcloseしていたのが原因。 標準IOをclose()する事は別に間違いでは無いように思うのですが(一部ではいけない という説もある様ですが)、標準IOは親プロセス(この場合シミュレータ)と共用 なので、シミュレータ上で動かす場合には、都合がよろしくありません。 で、標準入出力はcloseしないようにシステムコールエミュレーション内で 押さえてしまう事にしました。
後は、stat()。以前POV-Rayでlstat()をエミュレートした時にエンディアンを 修正しないでそのままほって置きましたが、やっぱり良くない模様(^^;。で、 stat構造体のメンバーのエンディアンを反転する関数を追加。シミュレータ メモリ内はビッグエンディアンとして、エミュレートする時に反転関数を呼んで 反転し、リトルネイティブなstat()を実行します。stat()実行後で、再び反転 関数を実行すれば、ビッグエンディアンになるというしかけ。
これで実行した所、du: virtual memory exhaustedというメッセージに変わり ました(^^; 再び調べてみると、open()でディレクトリをオープンしようとして、 エラーとなっている模様。ところが、先日opendir()関数を追加しましたが、この中 ではディレクトリをopen()するのは正当な模様。つまり、先日のreaddir() 同様、opendir()も使えなかったという事が発覚(^^;;。従って、opendir()も システムコールに格上げする必要がありそうな、そんな予感がします.......

7/16分の日記を補完してみました(^^;

何もなっしん。うーん、うーん、.....

何もなっしん。うーん、続くとまずいなぁ(^^;......

ビール臭で起床(汗;。シャワーくらい浴びて寝るんだった(^^;;;;;;;;

休出(T-T)

夕方、今日も飲みに新宿で待ち合わせ。
今日は、前回私は行くことができなかった 「バドガール満載の店」ですよ。 オオスカシバさん(お初でしたm(_'_)m)のご案内で、まさちくさん、村上さん、 そしてＫＯＪＩさん、はすみちゃん、私というメンバーで新橋へ向かいました。 途中、冗談で 「店が閉まってたらどうしよう？あはは」 などと言っていたのですが、 本当に閉まってますよっっっ!! (TOT) あまりのショックと暑さで、溶けましたとも、ええ。つーか、ほとんど マンガですよ。ふぅぅうぅぅ ...るるるぅ〜〜〜〜りららら〜〜〜〜....(;__)/□
しかた無いので、また新宿に戻る事にしました(笑)。

で、まさちくさんの案内で、その辺の店に入ろうとしたのですが、満杯で入れず。 その時、村上さんが「新宿でバドの店に連れていってもらった事あったけどなぁ .....」と一言。ぴきゅいぃぃーーーん(-_-*これは バドガール神からの啓示に違い無い(どんなんや)。村上さんの受信する啓示に 従い(だた記憶を辿っていただけです)行き着いたその先に、 ありましたよ 「Budweiser Carnival」がっ！！ ボクらは見放されてませんでしたよ！(誰に?) 「ここも満杯だったらどうしよう？」とはすみちゃん。 「いいや、その時はヲレだけでもっ！」。でも、 心配は無かった模様。安っぽい遊園地のアトラクションの様な通路を抜けたその先に 広がるは、 「バドガールの群」.....いやいや、今日は日曜日だし、 明日もあるし、そんな感じで４人しか居ませんでしたが、 「生バドガール」が歩いてますよ！ あぁっ もう思い残す事なく逝く事ができますよ(＜死ぬなよ)。
そんな訳で、



そんな感じ。
飲み中は、PowerXの話とか、オオスカシバさんの昔のBBSハンドルの話とか、 実は私(ら)もそのBBSつながりだったりとか、まさちくさんとはすみちゃんの 住んでいる所が近かったとかで微妙なつながり炸裂！他、もう色々。大変、 楽しゅうございました。

帰りに、レジに置いてあったマッチを、はすみちゃん が眺めて「他にも色々ある んやねぇ」。確かに、全国(つっても本州内のみですが)に店舗があるらしい。 ニセ(謎)も含めば数え切れない事は明白ですが(^^; で、そのマッチには バドガール二人の写真が印刷されていたので、タバコを吸わないくせにマッチを 奪い取り、落書きCGの資料にしたのだとさ。
次回は秋のフェスタですね。その時はぜひ新橋の方で！ (＜ええかげんにせーっちゅーの)

ＫＯＪＩさんのモーニングコール(とは言っても昼前でしたが(^^;)で起床。 暇を持て余しているとの事なので、早速合流する事にしました。昼飯を食って、 彩の話やら、Power-Xの話やら、もう色々。
ひとしきり時間を潰して はすみちゃん(ＫＯＪＩさんのお知り合い。 かわいいのだ*^^*)と合流して、飲み屋に。
一発目の飲み物を注文してやってきたのですが、注文の品と違っていると気づいて 言ったその時！ ビール(生中×2)がひっくり返り、 モロに浴びてしまいましたよ！！(＞ヲレ) それはもう、てんやわんやの大騒ぎ、拭いても間に合わない濡れようですよっ(^^; で、どうにか片づいて、割引するという事で終了。注文のビールにサービスだと、 追加でビールのピッチャーを出して来たのですが、みんなビールが得意でなかった りして(^^;。 つーか、「雪○の牛乳でアレした お詫びで ○印の牛乳１年分をもらう様な気分」はどうかと思いますが。 ま、タダ酒なので良いですが。

終電前におひらき。ビール臭をふりまきながら帰宅。お疲れさまでした(^^)

彩 for Winがバージョンアップ されてました(^^)。今回はレイヤーが使える様になってますよ。今の所、レイヤー の枚数は４枚固定、ファイルIOは無しといった所。X68k版の時は、それなりのサイズ で描くと、４枚も重ねるなどとても無理でしたが、当たり前ながら全く余裕です (^^)。しかも速いし。
365pix以上のブラシサイズで不当エラーで落っこちるというバグがありますが、 今週中に直るかも。あと、レイヤーを使用して消えない線画で、着色ウハウハと いきたかった所ですが、消しゴム(透明で塗る)が無いので、線画を修正する事が できません(^^; この点も近いうちに実装されるかも。この辺が整えば、取りあえず ガシガシ描く事ができそうな予感がします。

何もなっしん。

fileutils。
readdir()はシステムコールに格上げ(?)して対応。あと、PPCLIBの方も システムコールを追加してlibc.aを更新。とりあえず、duコマンドのリンクに 成功しました(^^)v。
du --help は改行が変ですが、一応OKそう。du本体の実行は0が返ります(^^; ううむ。あとduを実行すると、実行後、標準出力が狂ってしまうみたいで、二度目 の実行では、

du: write error

fileutilsの続き。
シミュレータでエミュレートするシステムコールを追加。ところが getdents() が見つからないため、リンクに失敗(^^;。という事は先日dirent.hがらみで ごちゃごちゃいじった関数readdir()などは、結局 使えない事に。しくり。

もう一度Cygwinでのreaddir()などの実装方法を調べないとダメちっく.....

日記補完(^^;
本物お仕事が忙しくて、あぅあぅ、ずぶぶぅ.......(＜沈むなよ)

実装きゃど氏のお誘いで、映画を観に行きました。風邪が治っていないので、くしゃみ が出始めるとしばらく止まらないのがピンチです(^^;;;
当初、ジュブナイルを観ようとしていたのですが、公開一週間前だったというチョンボ をかましたため、「人狼」を観にゆく事にしました。個人的には、まぁOKという感じ。 その後、呑んで帰って寝た。呑んだせいで体調が弱まった気もしなくもありませんでし たが、気のせいだった模様。酔ってると調子の悪さ加減も麻痺するのでしょうかね？(^^;

そういや、行きの電車で、


こんな容姿の女の人が乗ってました(^^; 降りる時に気づいたので、しげしげと眺めては いないのですが、随分と鮮明な容姿だったので驚きました。 世の中、いろんな人がいるのだなぁと思いました。 ファッションなら少しはアレですが(いや そうでもないか)、 本当にその筋の人だったら、ちょっと怖かったかも。 どの筋なのかはよく判りませんが。

起きたらすっかり台風が通り過ぎていたので、休出(T-T)

RCSの調査。どうやら編集できないのはMeadow上だけの話らしい。RCS管理されて いる場合、lisp/vc.elが動作して、様々な機能が有効となるらしい。このとき、 RCSディレクトリからlockしているユーザを取得し、編集を行おうとしている ユーザと比較を行う様なのですが、この編集を行うユーザはMeadowのLISP (user-login-name)で取得しています。所が、eval-expression で(user-login-name) の戻り値を見てみると、メタメタな文字列が返っていました(^^;。おらく、 「既定」なのでしょう。このため、ユーザ名をマッチさせる事ができないため、 編集できないという事になっている様です。
Windowsのファイルシステムでは、group,other users のフィールドをchmod 666 とかやっても立てる事ができない様なので、vc.elをいじってユーザを騙せば、 強引に使う事は可能だと思われます。でも、あまり美しくありません。一番良い のは「既定」を変える事なのですが......ううむ。前述の通り、group,other users のフィールドが変えられないのならば、マルチユーザ管理になっても、オーナー パーミッションという概念は導入できないハズ(マルチユーザ管理になった途端に 効き始めると別ですが(^^;)なので、これでユーザ名を変えてしまうしか無いの かしら？..........うーん、めんどい。ほったらかしにしよう(^^;;

夏風邪復活気味なので死亡........

単に環境変数USER(もしくはLOGNAME)が設定が設定されていなかっただけだった らしい(大汗;;; 「$Id:$」の文字列が良くないのかと勘違いしてましたよ。 で、ci して co -l hoge.cでチェックアウトし、Meadowで編集しようとした所、 強制的にRead-Onlyで読み込もうとしてしまいます。どうやら、ファイルの オーナーシップが開いていないという事の様な予感。

システム情報を見てみると、なんとユーザ名が本当に"既定"になってますよ(^^; ciのエラーのそれとこんな所で関係が！という事は、USERが設定されていないと いうのは、あまり関係がなくて、そもそも「既定」という(ASCIIでない)ユーザ名 がciと合わなかったと言う事になりますか？
あと、ls -l でファイルユーザフィールドが文字化けしているのを気にせず ほったらかしにしていたのですが、ls -l の出力をバイナリダンプで眺めてみた 所、「既定」のコードに対応する4byteが表示されていました。ううむ。

はて、困りました。「既定」とは何のことやら、なぜ「既定」になっているのか、 どうすればユーザ名を変えられるのか、複数ユーザ設定が可能らしいので、 それで新規ユーザを追加すれば良い気がしましたが、その時、既存のファイルの オーナーシップはどうなるのか(編集できなくなる？！)、 さっぱりわかりません(^^; とほり。

fileutilsで必要なシステムコールのまとめ。

なにげにCVS/RCSが使えるのかしら？という事でうぇぶぐる。CVSの方はCygwin バイナリが存在していましたが、RCSの方は自分でコンパイルするものらしい。 RCSの最新版を拾って、configure,make。所が、makeでこけます(^^;(正確には src/conf.shの実行が失敗する) それらしいサイトを回ってみても、特にmakeで こける様な事は無いらしいのですが......あ、 パッチは存在するらしい。どうにもうまくいかないので、なにげに src/Makefile のSHELLを/bin/bashに変更してみました。すると、通りましたよ(^^; ashのパッケージがなんとなく怪しい臭いです。
で、できあがったciコマンドを実行......

RCS/bi_cmd.c,v  <--  bi_cmd.c
ci: invalid identifier `既定'
ci aborted

宴会から帰って即死(^^;

fileutils。
先日のdd_が見つからなかった件は、libc/sys/の下に各種機種依存ファイルファイル があるのですが、その中のいくつかのシステムのsys/dirent.hに含まれている事 が判明。ただし、どれを使うのが良いかは不明(^^; 折衷案(?)という事で全部の andを取って盛り込んでみました。
最終的にtime(),ioctl(),lstat(),pathconf(),readlink(),readdir(),fcntl(), getcwd(),chdir()などのシステムコール系と、getpwuid(),getpwnam(),getgrnam() などのpwd.hに含まれる関数が見つからないという事になりました。
所が、pwd.h系に含まれる関数のソースがnewlib内のどこにも見あたりません(^^;。 Cygwin本体のソースを拾って探してみたのですが、これにも見あたりません。 fileutils自体はCygwin上でネイティブコンパイルできるので、Cygwinライブラリ には含まれていても良いハズなのですが........ううむ。

fileutilsの続き。
opendir(),closedir(),readdir()などがリンク時に見つから なかったのですが、newlibのlibc/posixディレクトリの下にはちゃんとソースが 入っていました(^^; どうやらHAVE_OPENDIRがdefineされている為、空オブジェクト になっていた様です。-DHAVE_OPENDIRをMakefileから外してmakeし直してみました。 が、エラーが出て止まりました(T-T)

closedir.c:54: structure has no member named `dd_fd'
closedir.c:55: structure has no member named `dd_fd'
closedir.c:56: structure has no member named `dd_loc'
closedir.c:57: structure has no member named `dd_buf'

休出。にわかに本物お仕事の方が忙しくなってきてて、開発ペースが落ちてい ますよ。

binutils-2.10で、.sbss重なり問題が解決してればラッキーだと思い、 povrayをリンクし直して、シミュで実行した所、OKでしたよ!!(^o^) これはラッキーな出来事だったかも。因みに、PNGセーブが変だったのは、 povray.iniとライブラリをインストールしたら大丈夫でした。多分、TARGA フォーマットか何かになっているのでしょう(詳しく追求せず)。

なにげにgslのページを 見てみると、gsl-0.6 というのがリリースされていました。前回の0.5は、 make checkがこけるという トホリなバージョンでしたが、今回は大丈夫 でした(^^)
でも、コンパイル＋make check で、えらく時間がかかった ので、テストで使う場合は、比較的完成されたシステムの上で使った方がよさ そうです。

思いっきり昼まで寝こけてました(^^;
ニセsh上でPOV-Rayを実行してみました。ヘルプの改行がメタメタなので、 再コンパイル。OKそう。でも、メモリ領域をオーバーしてこけている みたいですが.....(^^;。取りあえずヘッダファイルを使用しないテスト を実行。実行終了したものの、できあがったPNGファイルがなんだか変。 +FPで PPMファイルに出力した所、OKそう。うーむ。zlibとlibpngも 再コンパイルしてみるけど変わらず。ぐふっ。

Cygwinのツールをアップデート。所が、binutils-20000625.tar.gzを入れて PPCクロスbinutilsを再コンパイルしようとしたら、collect2が./ldを探そう としてこけました(^^;。binutils-19990818-2.tar.gzに戻しました。

なにげにfileutilsをクロスコンパイルしてみました。 結果、惨敗でした(T-T)。 dirent.h関連はnewlibに含まれていない様なので、この辺は全滅な様です。 取りあえず、Cygwinの方からヘッダファイルを拾ってなんとかリンクまで 持ち込みましたが、ディレクトリ操作関連、ioctlなどのシステムコールの 実装が必要な様です。うーむ。

うぇぶぐる。binutils-2.10がリリースされていた模様。どうやら、Cygwinの それは、これの事だったらしい(^^;(＜気づけよ)
拾ってきてクロスbinutils-2.10のconfigureを実行してみましたが、先ほど のクロスbinutils-2.9.1のconfigureと同じく、collect2のせいでこけました。 Cygwinのbinutilsは19990818版に戻してあるので、どうやらbinutils-2.10の 方に問題がありそうな予感がします。取りあえず、/usr/bin/ld.exeをコピー したらconfigureは先に進みました。.........なんだかものすごく時間が かかるのですが(^^;........終了。makeを仕掛けて撃沈。