uwoodyから開発に必要なBaseの部分の再構築まであともう一歩。
./i386/binutils-2.14.90.0.8-0a1.0.i386.rpm
./i386/gcc-3.3.4-0a1.0.i386.rpm
./i386/libgcc-3.3.4-0a1.0.i386.rpm
./i386/gcc-c++-3.3.4-0a1.0.i386.rpm
./i386/libstdc++-3.3.4-0a1.0.i386.rpm
./i386/libstdc++-devel-3.3.4-0a1.0.i386.rpm
./i386/gcc-objc-3.3.4-0a1.0.i386.rpm
./i386/libobjc-3.3.4-0a1.0.i386.rpm
./i386/gcc-g77-3.3.4-0a1.0.i386.rpm
./i386/libf2c-3.3.4-0a1.0.i386.rpm
./i386/cpp-3.3.4-0a1.0.i386.rpm
./i386/uClibc-0.9.26-1a1.0.i386.rpm
./i386/uClibc-devel-0.9.26-1a1.0.i386.rpm
./i386/texinfo-4.7-5a1.0.i386.rpm
./i386/info-4.7-5a1.0.i386.rpm
./i386/m4-1.4.1-16a1.0.i386.rpm
./i386/bison-1.875c-2a1.0.i386.rpm
./i386/libtermcap-2.0.8-39a1.0.i386.rpm
./i386/libtermcap-devel-2.0.8-39a1.0.i386.rpm
./i386/bash-3.0-17.i386.rpm
./i386/libtool-1.5.6-4a1.0.i386.rpm
./i386/libtool-libs-1.5.6-4a1.0.i386.rpm
./i386/gettext-0.14.1-12a1.0.i386.rpm
./i386/gettext-devel-0.14.1-12a1.0.i386.rpm
./i386/sed-4.1.2-4a1.0.i386.rpm
./i386/zlib-1.2.1.2-1a1.0.i386.rpm
./i386/zlib-devel-1.2.1.2-1a1.0.i386.rpm
./i386/byacc-1.9-28a1.0.i386.rpm
./i386/flex-2.5.4a-33a1.0.i386.rpm
./i386/gcc-java-3.3.4-0a1.0.i386.rpm
./i386/libgcj-3.3.4-0a1.0.i386.rpm
./i386/libgcj-devel-3.3.4-0a1.0.i386.rpm
./noarch/dejagnu-1.4.4-2a1.0.noarch.rpm
./noarch/autoconf-2.59-5a1.0.noarch.rpm
./noarch/autoconf213-2.13-9a1.0.noarch.rpm
./noarch/automake-1.9.2-3a1.0.noarch.rpm
後は、一つづつ依存性の問題を潰していくだけ。
もっとも、現状FedoraCore3をuClibc上で作っているだけで、何かチューニングしているわけでもなし。
チューニングして本来の目的に沿ったものにするにはまだ大分かかりそう。
binutilsとgccがようやくrpmになった。
uclibcのbuildrootより、binutils-2.14.90.0.8と、gcc-3.3.4を使用する。
binutils-2.15.Xとgcc-3.4.Xはまだマイナーバージョンが上がりつつあるのと、まだ対応していないソフトウェアもあるので、ここ2-3年を見越すとこの辺が妥当と思われる。
Antique Linuxでは長く使えるtoolchainがベターであり、新しいものを入れる必要はないと思うからだ。
(次の日記更新は年明けの予定。)
○rpm 4.0.4/4.1/4.1.1/4.2.3いずれも駄目。理由はどうやらスレッドのシンボルが噛み合わない模様。気を取り直して、binutilsから独自に作り直すことにする。
○スレッドを取り入れていないrpm 3.0.6を試したところFLT_MAX/FLT_MINが未定義な点以外はうまくいった。ちなみにFLT_MAX/FLT_MINの値はCygwinのパッチに含まれていたものを借用。そのうち4.1.1に戻ってくる予定なので、暫定仕様だが構わないだろう。4.1.1ではこれらの点では引っかからなかったので。あ、あとdb_openではなくdb185_openを呼び出すようにする。これもCygwin用パッチからの転用で、db3と同居するために必要。
WGWのメインマシンは未だにDual Celeronマシンである。
各自これにログインして使用しているのだが、今回のコンパイル作業では待ち時間が長いので、リプレースを考えている。
問題はALを開発している仮想マシン環境(VMWare 4.0.X)のバージョンを上げるための金がなく、今のバージョンで動く必要があることかもしれない。となると、AMD64とかは駄目かなぁ。Pen4 Extreme...はキャッシュが多いのがよいけど高すぎる。SSE2とか絶対不要だし... ここはPen3の後継のPentium M?
んー、ちまたの評判でも探してみようかな...
まぁ、仮想マシン取っ払う手もあるのだけど、仮想マシン上の方が何かと安全なんだよなぁ。
RPMのバージョン選定からいきなり迷う。
とゆーのは、rpm 3.0.6なら動作確認済みなのだが、最近はrpm 4.1以降を要求するものが少なくない。
さらに、rpm 4.0は重かったのがrpm 4.1以降はrpmbuild関係が分離されたのかやや軽くなったし、ファイルのパッケージし忘れをチェックするスクリプトがつくなど、使い勝手が向上している。
というわけで、まあ良いかなと思ってrpm 4.1をビルドするとuwoody付属のgcc 3.3以降ではコンパイルできなかったりする。
rpm 4.2以降ならgcc 3.3でもコンパイルできるのだがselinux関連がべったりくっついていて厄介だ。そこでrpm 4.0.4も試したのだがthread関連で不備があるようだ。(でもこれuClibc側の不備な気もする。)
今日はrpm.orgで見つけた4.1.1に挑戦してみようと思う。
まあTCCのRPMをコンパイルするためにRPMをちょっと作ってみようかという気だったので、場合によってはTCCをtarballから先に作ってrpmに取って返す手もあるかもしれん。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー