ここに示す移行手順の目的は、a.out と ELF の双方をコンパイルして動
かすことのできるシステムを構築することです。そのためには双方のプログラ
ムが適切な共有ライブラリを見つけられなければなりません。このためには、
他のいくつかのシステムがやっているように、単純に `/lib
と
/usr/lib
そしてコンパイル時に指定されたディレクトリを全て探す'
という方法よりも多少なりとも賢い方法が必要です。
賢い方法の中心に位置するのがシステムの上に一つ、あるいは二つ、存在する
動的ローダです。a.out のプログラム用には /lib/ld.so
、
ELF のプログラム用には /lib/ld-linux.so.1
がそれぞれ動的ロー
ダになっています。コンパイラやリンカは出力するプログラムにライブラリへ
の絶対パスを埋めこむことはしません。その代りに、ライブラリ名と適切な動
的ローダへの絶対パスを埋めこみます。そして、実行時に、(動的ローダが)適
切なライブラリに結びつけるわけです。ここに重要な秘密があります -- すな
わち、あるプログラムが使っているライブラリが別のディレクトリに動かされ
ても、プログラムを再コンパイルする必要はなく、ld.so
(あるいはld-linux.so.1
) に新しいディレクトリを探しに行くように
指示するだけで済みます。これが以下に述べるディレクトリを入れ替える操作
の骨子です。
上記から導かれる結論として、ld.so
を削除したり移動させたりす
れば、動的リンクを使っているプログラムは全て機能しなくなる、
ということがわかります。これは良くないことである、と一般に考えられてい
ます。
ですから、基本的な計画としては、ELF 用の開発環境(コンパイラ、インクルー
ドファイル、ライブラリ)を、今は a.out 用のものがある
/usr/{bin,lib,include}
に置き、a.out 関連のファイルは
/usr/i486-linuxaout/{bin, lib, include}
へ移すことにします。
/etc/ld.so.conf
はライブラリが見つかるであろう場所全てのリス
トになっており、ldconfig
は ELF と a.out を見わける能力を持っ
ています。
ライブラリの場所には多くの例外があります。
ld.so
を使わずに作られてい
ます。これらのプログラムはライブラリが別の場所に移動すれば動かなくなり
ます。ですから、もしそのようなプログラムを使っているならば、
libc.so*
や libm.so
は/lib
にそのまま残して
おかねばなりません。ELF 用のライブラリは主バージョン番号が異なっている
ので、a.out と同じディレクトリに置いても上書きしてしまうことはありませ
ん。古い X 関連のライブラリ(version 6 以前)もそのままの場所に残してお
くのがいいでしょう。一方、新しいバージョン(libX*so.6
は別の場
所に置かねばなりません。古いライブラリを動かすと、xview 関連のプログラ
ムが動かなくなり、新しいライブラリを別の場所に置くようにしないと ELF
用の X ライブラリをインストールした際に古いものに上書きしてしまいます。
上記以外のライブラリを必要とする ld.so を使っていないプログラムをお持
ちなら(どのプログラムが該当するか分っていれば、前もってそれら
のプログラムを ldd
で調べて、必要なライブラリをチェックしてお
きましょう)、2 つの方法があります。一つは、ELF ライブラリを仮のディレ
クトリに展開して、必要なライブラリに上書きされるかどうかを確認すること
です。もし上書きされるようならば、ELF 版のライブラリは /lib
とは違う場所、例えば /usr/i486-linux-lib
へ置くようにします。
そして ldconfig
してそのディレクトリが参照されるようにします。
もう一つの方法は問題のプログラムの新しいバージョンを入手してコンパイル
し直してしまうことです。これはソースコードが入手可能ならば、そう悪いア
イデアではありません。
/usr
と /
が別のパーティションになっている場
合、/lib
から動かすライブラリは、/usr
のあるパーティ
ションではなく、ルートパーティションのあるディスク上に置く必要がありま
す。以下の例では /lib-aout
に置くようにしています。
/lib/elf
に ELF
用のライブラリ(通常は libc.so.4
など)があるかも知れません。これらのラ
イブラリを使うアプリケーションは再コンパイルする必要があります。その上
でこのディレクトリは削除しましょう。/lib/elf
ディレクトリは不
要です。
/sbin/
何たら' を使うようになっているのに、自分のシ
ステムには /sbin
ディレクトリが無い場合、それらのプログラムは
/bin
か /etc
にあるはずです。新しいプログラムをイン
ストールする場合、特にこの問題には注意してください。コマンドを検索する
パスリストで /etc
が /sbin
よりも前になっていれば、
知らないうちに(/etc/にある
)古いバージョンのコマンドを起動して
しまい、妙なエラーを起す場合があります。
必要なパッケージは、 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ や ftp://sunsite.unc.edu/pub/Linux/GCC/ から入手可能です。両サイト とも多くの場所にミラーされていますので、可能なかぎり近くにあるミラーサ イト[訳注:日本ならば ftp://ftp.iij.ad.jp/pub/linux/sunsite/GCC/ や ftp://ftp.spin.ad.jp/pub/linux/sunsite.unc.edu/GCC/ など ] から探してください。その方があなたにとっても、みんなにとっても、結局速く 入手できることになります。
以下に示すパッケージ(リストにあがっているバージョンかより新しいもの)が
必要です。これらをダウンロードして、それぞれに付属している文書を読んで
みてください:必要な文書はたいてい release.
packagename とい
う名前になっています。以下に示しているバージョンよりも新しいバージョン
を入手した場合、必ずリリースノートに目を通してください。それら新しいバー
ジョンではインストールの方法が変っているかも知れません。
プログラムは常にソースからコンパイルするという人でも、以下に示すプログ ラムはバイナリ版を入手してお使いになることを強くお勧めします。これらの プログラムのほとんどは a.out 版のシステムで ELF 形式を生成するようには 設定されておらず、a.out の環境でコンパイルしようとしても無駄です。
ld.so-1.7.14.tar.gz
--- 新しい動的リンカ。ソースとバイ
ナリが 入っています。これ以降のバージョンでは a.out バイナリを使う場合
でもカーネルに ELF サポート機能を組みこんでおく必要があります。もし
1.8.1 やそれよりも新しいバージョンをお持ちの場合はインストールする前に カーネルに ELF サポート機能が組みこまれているかを確認してください。
libc-5.3.12.bin.tar.gz
--- ELF 形式の共有ライブラリで
C と数学ライブラリ、その他関連する静的ライブラリやそれらを使ってプログ
ラムをコンパイルするのに必要なインクルードファイルが入っています。必要
でしたらソースコードも入手できますが、コンパイルするには時間がかかりま
すし、ELF システムを持っていないとコンパイルすることは不可能でしょう。
gcc-2.7.2.bin.tar.gz
--- ELF 対応の C コンパイラ。新しいディ
レクトリ・レイアウトを理解する a.out 対応の C コンパイラも入っています。
gcc を自分でコンパイルしたい場合(やるとしても ELF 環境に移行してからの
方が簡単だと気づくでしょう)、GNU のオリジナルのソースコードに
gcc-2.7.2-linux.diff.gz
パッチをあてた方がいいでしょう。
/binutils-2.6.0.12.bin.tar.gz
--- Linux 用にパッチ
をあてた GNU バイナリユーティリティです。このパッケージには
gas
や ld
、strings
などのプログラムが含まれ
ており、C コンパイラを使うには必須になっています。素のままの GNU
binutilities (例えば prep.ai.mit.edu
にあるような)では代りに
ならないことごに御注意ください。どうしても自分でコンパイルしたい場合は
GNU のものではなく、Linux 用にパッチを当てた binutils-2.6.0.12.tar.gz
を使ってください。
ncurses-1.9.9e.tar.gz
--- SVR4 互換の curses ライブラ
リで、これからの Linux 用「標準 curses ライブラリ」であると考えられて
います。ソースコードは
ftp://prep.ai.mit.edu/gnu/ のような
GNU のサイト、あるいは
ftp://ftp.netcom.com/pub/zm/zmbenhal から入手でき、
tsx-11
にはバイナリパッケージも用意されています。このパッケー
ジをインストールする時には既に完全に ELF 化された開発環境に移行してい
るはずなので、マシンパワーがある場合はソースコードを入手した方がいいで
しょう。
gdbm-1.7.3.tar.gz
--- Unix の標準となっている dbm や ndbm
ルーチンと互換の、拡張ハッシュ機能を持ったデータベースルーチンです。ソー
スコードは
ftp://prep.ai.mit.edu/gnu/ から入手できます。共
有ライブラリ版を作るには
ftp://ftp.uk.linux.org/pub/Linux/libc/non-core/gdbm.patch を当
ててください。このパッチはその他いくつかのバグを修正しています
(Makefile にある一文字の typo や間違った種類のファイルロッキングを使う
傾向など)。
上記以外にも、必須ではありませんが入手しておいた方がいいライブラリ やファイルがいくつかあります。以下に示すものは ELF で使うためにバージョ ンアップしなければならない類いのプログラムです。この文書の後半では、そ のままでも使えるものの、ELF 形式でコンパイルするには修正やバージョンアッ プが必要なプログラムを紹介します。ネットとの接続が遅い場合(例えばフロッ ピーの箱を抱えて 5 分間歩いているくらい時間のかかるような)、以下のファ イルは飛ばして、設定を終える前にこの文書の後半部にあるそれぞれのプログ ラムについての記述と合せてチェックしてください。
libc.so-4.7.6
。
このパッケージが「オプション」になっているのは、手元にある既存のバイナ
リを動かすことのできる a.out ライブラリがあれば、それはそのまま使える
からです。このライブラリは何らかの理由で今後も a.out 形式のプログラム
を開発せねばならない時に必要になります。
libcurses.so.1
を必要とするバイナリがあれば、これが古い BSD
curses ライブラリです。このライブラリのソースコードは今のところ見つかっ
ていないのですが、このライブラリでしか動かないプログラムはごく稀なはず
です。その種のプログラムがあれば、ncurses を使うようにコンパイルし直し
た方がいいでしょう。そうできない場合は libcurses.so
が
tsx-11
とそのミラーサイトにある
libc-5.0.9.bin.tar.gz
に含まれています。
libdb
データベースルーチンです。ソースコー
ドは
ftp://ftp.cs.berekeley.edu/ucb/4bsd/db.1.85.tar.gz/
で、Linux の共有ライブラリ用のパッチは
ftp://ftp.uk.linux.org/pub/Linux/libc/non-core/db.patch にあり
ます。
gcc
パッケージは g++
と共に配布されていますが、有用
な C++ ソフトウェアをコンパイルするには libg++-2.7.1.4.bin.tar.gz
が必要です。私自身は C++ を使っていませんが、聞くところによると、
このライブラリをソースコードからコンパイルするのは結構大変だそうです。
ですから、バイナリ版をお勧めします。
gdb
がそのいい例です。
共有ライブラリをデバッグしたいけれど、gdb が自分自身へリンクしているラ
イブラリを前にして混乱するような場合、静的にリンクしたバイナリを使うべ
きでしょう。その場合、本当の termcap は ncurses に含まれている termcap
互換のルーチンに比べてずっと小さいことに気づくでしょう。
termcap-2.0.8.tar.gz
は tsx-11
から入手できます。こ
れは GNU Termcap とは異なりますが、完全に互換です(違いはエラー
チェックの部分だけです)。これはソースコードのパッケージになっています。
/dev/zero
を削除してしまえば、いくつかのバージョンの ld-linux.so.1
が動
かなくなります。新しいバージョンの MAKEDEV は
ftp://sunsite.unc.edu/pub/Linux/system/Admin/MAKEDEV-C-1.5.tar.gz
か
ftp://sunsite.unc.edu/pub/Linux/system/Admin/MAKEDEV-2.2.tar.gz.
にあります。
modules-2.0.0
モジュールを使っている場合、binutils をバージョンアップすれば 1.3.69
以前のモジュール・ユーティリティは使用できなくなります。新しいモジュー
ル・ユーティリティは
http://www.pi.se/blox/ にあります。
ftp.xfree86.org
ですが、国内にも多数のミラーサイトがありま
す(例えば ftp.iij.ad.jp
)ので、ネットワーク的に近いサイトから
入手してください。これらのサイトからcommon
とelf
ディ
レクトリ以下を入手したら、/usr/X11R6/lib/X11/config/linux.cf
ファイルの中の以下の2行のNO
のところを
#define LinuxElfDefault NO
#define UseElfFormat NO
YES
にしてください。そうしないと xpm をコンパイルする際に
jumpas
で昔の名残りの奇妙なエラーが生じます。現在の XFree86
のバイナリは ELF 化された termcap ライブラリlibtermcap.so.2
がインストールされている必要があることに注意してください。
Motif を使っている場合は、ELF 化された Motif ライブラリを提供する予定
があるかベンダーに問いあわせてください。私は Motif は使っていないので
何の役にも立てません。
Documentation/Changes
ファイルを
忘れずにチェックして、必要なものがどこで入手できるか調べてください。
え〜っと、私が以下で「削除する」と言った場合、「バックアップを取っ てから削除する」と読みかえてください :-) まず、深呼吸して、、
エッセンス --- バイナリ・インストール
mkdir -p /usr/i486-linuxaout/bin
mkdir -p /usr/i486-linuxaout/include
mkdir -p /usr/i486-linuxaout/lib
mkdir /lib-aout
ld.so-1.7.14
をいつものソースコー
ドを置いている場所で展開し、取り出された
ld.so-1.7.14/instldso.sh
スクリプトを読んでください。本当に標
準的なシステムをお使いなら、sh instldso.sh
を実行してインストー
ルすることができますが、何か非標準的なものを組みこんでいる場合、手動で
インストールすることになります。「何か非標準的なもの」とは、
$VERSION
と
いう変数を定義しており、instldso.sh
が混乱するようです)
/lib/elf
から /lib
へのシンボリックリンク(これは必要
なわけではありませんが、レスキューディスクが必要になるような場合には多
少の慰めになるかも知れません)
/etc/ld.so.conf
を修正して、
/usr/i486-linuxaout/lib
を加え(必要ならば /lib-aout
も加え)、/sbin/ldconfig -v
を再実行して、新しいディレクトリ
を探しにいくかチェックします。
/usr/*/lib
にある全ての a.out 形式の「ライブラリ」を
/usr/i486-linuxaout/lib
に移します。移すものは
lib*.so*
や lib*.sa*
、lib*.a
などの「ライブ
ラリ」であって、その他のファイルを移す必要はありません。
/usr/lib/gcc-lib
などもまだ動かしてはいけません。
/lib
をチェックします。libc.so*
や
libm.so*
、libdl.so*
はそのままにしておきます。X のラ
イブラリ(libX*.so.3*
へのシンボリックリンクもそのままにしてお
きましょう --- XView
等のプログラムがそれらのライブラリを使っ
ているかも知れません。ld.so*
、ld-linux.so*
など
ld
で始まっているファイルもそのままにしておきます。残りのライ
ブラリについては(もしあれば): ルートパーティションに /usr
が
あれば、そこにあるファイルは /usr/i486-linuxaout/lib
に移しま
す。/usr
が別パーティションにマウントされていれば、
/lib-aout
に移します。これで ldconfig -v
してみてく
ださい。
/usr/lib/ldscripts
ディレクトリがあれば削除します(binutils が
このディレクトリを新たに作ります)
/usr/bin
にある(ld86
と as86
以外の)全ての
ld
と as
のコピーを削除します。
/usr/include
以下のディレクトリを削除します。標準的な
システムでは、ここにあるファイルのいくつかはシステムの「核」となる機能
を担っており、libc と共に配布されています。それ以外にも、あなた自身が
インストールしたり、使っているディストリビューションの作成者がインストー
ルしたファイルもあるはずです。これらを整理するために、0 から作り直すこ
とをお勧めします。まず既存の/usr/include
を
/usr/include.old
に変更し、libc-5.2.18.bin.tar.gz
をルー
トディレクトリで展開します。
tar -
xvzf binutils-2.6.0.12.bin.tar.gz -C /
がお勧めの方法です。
/usr/bin
に、残りの多くのファ
イルを /usr/lib/gcc-lib/i486-linux/2.7.2
と
/usr/lib/gcc-lib/i486-linuxaout/2.7.2
にインストールします。
gcc をインストールするには、まず
$ tar ztf gcc-2.7.2.bin.tar.gz
として、何が入っているかをチェックしてください。残しておきたいファイル
に上書きするようであれば(例えば Gnu ADA をインストールしていれば
/usr/bin/gcc
を残しておきたいでしょう)、まずそれらのファイル
を安全な所に移します。その上で、
# tar -zxf gcc-2.7.2.bin.tar.gz -C /
とします。この時点で、gcc -v
して gcc のバージョンを確かめた
り、テスト用のプログラムをコンパイルして、きちんと動いているかチェック
してください。
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs
gcc version 2.7.2
$ gcc -v -b i486-linuxaout
Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.2/specs
gcc version 2.7.2
$ ld -V
ld version 2.6 (with BFD 2.6.0.2)
Supported emulations:
elf_i386
i386linux
i386coff
次に伝統的な ``Hello, world'' プログラムを試してください。そのプログラ
ムを gcc
や gcc -b i486-linuxaout
で、コンパイルし、
a.out と ELFのコンパイラが正しく設定されているか確認してみましょう。
終りましたかって?もう少し頑張って。まだいくつかのライブラリが残ってい
ます。また、シンボリックリンクをごちゃごちゃ張らないといけません。頑張っ
て、、
シンボリックリンク
/lib/cpp
を使います。/lib/cpp
は Linux では
/usr/lib/gcc-lib/i486-linux
version/cpp
にあり
ます。ここまでの段階で /lib
の下にあるシンボリックリンクは全
て削除しているはずなので、リンクを張り直す必要があります。
# cd /lib
# ln -s /usr/lib/gcc-lib/i486-linux/2.7.2/cpp .
/usr/include
以下を /usr/include.old
以下に移
すと、カーネルのソースコードへのシンボリックリンクが失なわれるので、
# cd /usr/include
# ln -s ../src/linux/include/linux .
# ln -s ../src/linux/include/asm .
としてリンクを張り直してください。
(ここではカーネルのソースコードは /usr/src/linux
にあると仮定
しています。そうでない場合、適切な場所を指定してください)
utmp
と wtmp
ファイ
ルを /var/adm
から /var/run
と /var/log
に
それぞれ移すことにしました。必要に応じて /var/log
や
/var/adm
を作り、utmp
や wtmp
の現在位置へ
リンクを張るようにしてください。私は以下の ls -l
に示すような
配置にしました。
$ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp
lrwxrwxrwx 1 root root 3 May 24 05:53 /var/adm -> log/
drwxr-xr-x 9 root root 1024 Aug 13 23:17 /var/log/
lrwxrwxrwx 1 root root 11 Aug 13 23:17 /var/log/utmp -> ../run/utmp
-rw-r--r-- 1 root root 451472 Aug 13 23:00 /var/log/wtmp
drwxr-xr-x 2 root root 1024 Aug 13 23:17 /var/run/
-rw-r--r-- 1 root root 448 Aug 13 23:00 /var/run/utmp
FSSTND の全体については
sunsite にあ る LDP のアーカイブなどにある文書をご覧ください。
おめでとう!
ここまでで(多少なりとも)完全に機能する ELF の開発環境が完成したはずで す。一歩下って、しばらく静かに喜びをかみしめましょう。
重要なソースコードのパッケージ
INSTALL
ファイル
を、自分が「Linux 何たらシステム」のディストリビューションの作成/まと
め役である、と思って読んでみましょう。すなわち、コンパイルの際には、多
分、以下のようなコマンドラインで設定する必要がある、ということです。
$ ./configure --with-normal --with-shared --disable-termcap --enable-overwrite --prefix=/usr
デフォルトになっているターミナルの種類にも注意しましょう。1.3 と 2.0
のカーネルでは、起動時のデフォルトのターミナルは linux
になっ
ています。場合によっては /etc/inittab
を修正して
console
や getty
にしなければならないかも知れません。
ルートパーティションのあるハードディスクに /usr/lib/terminfo
が無い場合、ncurses の `fallback' 機能でごまかす必要があるでしょう。こ
の機能は上述の INSTALL
ファイルに説明してあり、単純ですが、退
屈な仕事になります(ライブラリを 2 度作成する必要があります)。fallback
として linux
や vt100
を使えばいい場合、幸いなことに
既存の fallback.c
に置き替え可能な fallback.c
が
ftp.uk.linux.org に用意されています。
ncurses をインストールした後、/usr/lib
以下で多少面倒な仕事を
する必要があります。これは不定形な作業なので、手でやるのが最も簡単です。
バージョン番号が多少不一致になっていることに注意してください。これは醜
いですが、健康に害があるわけではありません。
/usr/lib/libncurses.so.1.9.9e
を /lib
に移し、
シングルユーザーモードでも curses プログラムが動けるようにします。ルー
トパーティション に /usr/lib
がある場合、特にこの作業は不要で
すが、やっておいても害はありません。
/lib
ディレクトリで libncurses.so.1.9.9e
から
/libncurses.so.3.0
へリンクを張ります。
/lib/libncurses.so.3.0
から
/usr/lib/libncurses.so
や /usr/lib/libcurses.so
、
/usr/lib/libtermcap.so
へのリンクも必要かも知れません。
# cd /lib
# mv /usr/lib/libncurses.so.1.9.9e .
# ln -s libncurses.so.1.9.9e libncurses.so.3.0
# cd /usr/lib
# ln -s /lib/libncurses.so.3.0 libncurses.so
# ln -s /lib/libncurses.so.3.0 libcurses.so
# ln -s /lib/libncurses.so.3.0 libtermcap.so
gdbm.patch
をあて、README
と
INSTALL
ファイルに目を通します。
構築の手順は以下のようなものになるはずです。
$ tar zxf gdbm-1.7.3.tar.gz
$ patch -p0 < gdbm.patch
$ cd gdbm-1.7.3
$ ./configure --prefix=/usr
$ make
$ make progs
$ su
# make install
# make install-compat
# cd /usr/lib
# ln -s libgdbm.so.1 libgdbm.so
# ln -s libgdbm.so.1 libgdbm.so.2
# ldconfig
最後の 2 つは古いバージョンとの互換性を保つためです。最近のディスト
リビューションでは libgdbm.so.2
というバージョンになっていま
すが、これは libdgbm.so.1
と全く同じコードで、バージョン番号
だけが歴史的な理由から間違えて付けられているものです。
オプションのソースコードパッケージ
一般に、それぞれのパッケージに付属の指示にしたがってインストールすれば 大丈夫なので、ここで繰り返すことはしません。ただし、例外が 2 つあり、
$ tar zxf termcap-2.0.8.tar.gz
$ cd termcap-2.0.8
$ make
$ su
# cp libtermcap.so.2.0.8 /usr/lib
# ldconfig
決して make install
は実行しないように。make
install
すると ncurses のプログラムを一部上書きしてしまいます。こ
のライブラリを使うようにコンパイルされた既存のバイナリを使うのではなく、
新たにこのライブラリを使ってプログラムをコンパイルする場合、ヘッダーファ
イルとスタティック・ライブラリをどこか別の場所に用意して -I
と -L
フラグを使ってコンパイル時にその場所を明示するようにし
てください。この部分は他の部分に比べて記述が曖昧だと思われるかも知れま
せんが、それには理由があります。すなわち、よほどの理由がないかぎり、
termcap を使い続けることはお勧めできないからです。
libdb
は以下のように作成します。
$ tar zxf db.1.85.tar.gz
$ patch -p0 <db.patch
$ cd db.1.85/PORT/linux
$ make
$ su
# mkdir /usr/include/db
# ldconfig
# cp libdb.so.1.85.3 /usr/lib ; ( cd /usr/lib && ln -s libdb.so.1 libdb.so )
# cp ../../include/*.h /usr/include/db
注意点としては
PORT/linux/OTHER-PATCHES
をあててはいけません。
db.patch
に含まれています。
/usr/include
以外の部分にインストールし、libdb
が
必要なプログラムをコンパイルする場合、C コンパイラのコマンドラインに
-I/usr/include/db
と指定してください。
以下に示すものは今までにインストールしてきたファイルのかなりおおま かな概観です。トラブルシューティングや削除すべきものを決める際にご利用 ください。
/lib
ld.so
(a.out 用)と ld-linux.so.1
(ELF 用)。 両者ともシンボリックリンクかも知れませんが、指しているファ
イルがきちんと存在することを確認してください。
libc.so.4
と
libm.so.4
(a.out)。これらはシンボリックリンクになっていますが、
正しいファイルを指しているか確認してください。
libc.so.5
と libm.so.5
、
libdl.so.1
、libncurses.so.1
、
libtermcap.so.2
(ELF 用)。これらもまたシンボリックリンクになっ
ているので、正しいファイルを指しているか確認してください。
/usr/lib
libbfd.so*
, libdb.so*
, libgdbm.so*
と
いった ELF 形式の共有ライブラリ
/lib
や
/usr/lib
にあるライブラリへのシンボリックリンクがここに必要で
す。リンクの名前は本当のファイル名からバージョン番号を取ったものです。
例えば、libc
について言うと、
lrwxrwxrwx 1 root root 14 May 2 20:09 /lib/libc.so.5 -> libc.so.5.3.12
-rwxr-xr-x 1 bin bin 583795 Apr 25 06:15 /lib/libc.so.5.3.12
lrwxrwxrwx 1 root root 12 Oct 27 1995 /usr/lib/libc.so -> /lib/libc.so.5
となります。これらのリンクは、リンク時に ld
が利用します。
libbsd.a
、libgmon.a
、libmcheck.a
と
/lib
や /usr/lib
にある ELF 形式の共有ライブラリ各々
に用意されているlib*.a
ライブラリ。これらは ELF 形式の静的ラ
イブラリです。大部分の人にとっては、共有ライブラリと同じ静的ライブラリ
があってもそれほど有難味はないでしょう。特に ELF 形式を使う場合には。
ELF では、共有ライブラリを使いながら gcc -g
オプションを指定
することも可能なので、静的ライブラリを組みこむべき理由はほとんどありま
せん。でも、ライブラリ自身をデバッグしたくなる日のために、それらの静的
ライブラリは残しておいた方がいいでしょう。
crt0.o
と gcrt0.o
。これらは a.out 形式の「プ
ログラム起動用の」ファイルです。特に避けることをしなければ、全ての
a.out 形式のプログラムにこれらのうちの一つのファイルがまずリンクされる
ことになります。
crt1.o
、crtbegin.o
、crtbeginS.o
、
crtend.o
、crtendS.o
、crti.o
、
crtn.o
、gcrt1.o
。これらは ELF 用の起動用ファイルです。
これらは上記 *crt0.o
と同様の機能を ELF 形式のプログラムに対
して行います。
/usr/lib/ldscripts
ld
用の各種ドラ
イバスクリプトを置くところです。このディレクトリには以下のようなファイ
ルがあります。
$ ls /usr/lib/ldscripts/
elf_i386.x elf_i386.xs i386coff.xn i386linux.xbn
elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn
elf_i386.xn i386coff.x i386coff.xu i386linux.xr
elf_i386.xr i386coff.xbn i386linux.x i386linux.xu
/usr/i486-linux/bin
ar
, as
, gasp
, ld
, nm
, ranlib
,
strip
これらは /usr/bin
にある実際のバイナリ操作用プログラムへのシ
ンボリックリンクです。
/usr/i486-linuxaout/bin
as
と、そのマクロ・プリプロセッサ
gasp
があります。
ar
, ld
, nm
, ranlib
, strip
--- これらは
/usr/bin
にある実際のバイナリ操作用プログラムへのシンボリック
リンクです。
/usr/i486-linux/lib
ldscripts
は /usr/lib/ldscripts
へのシンボリッ
クリンクです。
/usr/i486-linuxaout/lib
lib*.so*
があります。
a.out 形式のプログラムを動かすには必須です。
lib*.sa
は a.out 形式の共有ファイルのスタブ(stub)です。
共有ライブラリを使う プログラムを a.out 形式にコンパイルするために必要
です。a.out 形式にコンパイルすることが無ければ削除してしまっても構いま
せん。
lib*.a
は a.out 用の静的ライブラリです。a.out 形式で静
的にリンクされたバイナリを作るために必要です(例えば -g
オプショ
ン付きでコンパイルする時)。このファイルも a.out 形式のプログラムを作成
する必要がなければ削除して構いません。
ldscripts
は /usr/lib/ldscripts
へのシンボリッ
クリンクです。
/usr/lib/gcc-lib/i486-linux/2.7.2
/usr/lib/gcc-lib/i486-linuxaout/2.7.2
(以下の内容の大部分は親切なメールでいただいたものです)
その場合でも shell は動いているはずなので、多少工夫すれば shell の組み
こみ機能だけでかなりの仕事をこなすことが可能です。echo *
は
ls
の代わりに使え、echo >>filename
はファイル
に書き足すのに使えます。ldconfig
も静的にリンクされていること
をお忘れなく。例えば、libc.so.4
を間違って lib-aout
ディレクトリに移してしまった場合、echo "/lib-aout"
>>/etc/ld.so.conf ; ldconfig -v
すれば、復旧します。
/lib/ld.so
を動かしてしまった場合、 静的にリンクされた ln が
あれば、sln /sillyplace/ld.so /lib/ld.so
することで、多分復旧
するでしょう。
bad address
ELF 形式のプログラムを動かそうとすると、いつもbad address
エ
ラーになる場合、多分、カーネルの 1.3.x の x <3 の
バージョンをお使いなのでしょうが、そのバージョンを使ってはいけません。
それらは多分、最悪のバージョンの一つです。2.0 へバージョンアップするか
1.2.13 にバージョンを落しましょう。似たような環境でカーネルパニックが
発生すると報告している人たちもいますが、私は詳しく調べていません。なぜ
なら、開発版のバージョンを使いたいとも思わないし、使う必要があるとも感
じないので、最新版の追っかけはしていないからです。
gcc: installation problem, cannot exec something: No such file or directory
a.out 形式でコンパイルしようとして(something の部分はたいてい
の場合 cpp
か cc1
のはずです)、このエラーが生じる場
合、実際に cpp
や cc1
に問題があるか、
$ gcc -b -i486-linuxaout
のように入力したのでしょう。実際には
$ gcc -b i486-linuxaout
と入力しなければなりません。`i486'の部分はダッシュではじまらないことに 注意してください。
make: *** No targets specified and no makefile found. Stop.
このエラーが出る場合、make
にパッチをあてて再コンパイルしてい
ないか、古いバージョンの make
がシステムのどこかに残っている
のでしょう。
no such file or directory: /usr/bin/gcc
実際にそのファイルが存在するのにこういうエラーが出る(gcc 以外のプログ
ラムでもこうなるかも知れません)。この場合、ELF の動的ローダー
/lib/ld-linux.so.1
をインストールしていないか、何らかの理由で
ローダーが読めない状態になっているのでしょう。先に述べたインストールス
テップの 2 を読んで /lib/ld-linux.so.1
を正しくインストールし
てください。
not a ZMAGIC file, skipping
このエラーは ldconfig
が出しています。古いバージョンの ld.so
のパッケージをお使いのようなので、新しいものを入手してください。もう一
度、インストールのステップ 2 を読んでください。
_setutent: Can't open utmp file
このメッセージは xterm を起動した時に 3 行ずつ出力されることがよくあり ます。インストール手順の最後のあたりにある FSSTND の長文の説明を読んで ください。