The Linux ELF HOWTO <author>Daniel Barlow <tt><daniel.barlow@sjc.ox.ac.uk></tt> <date>v1.01, June 1995 <trans>こじまみつひろ (1995/07/14) <tt><kojima@komae.denken.or.jp></tt> <abstract> この文書は、あなたの Linux システムで ELF バイナリフォーマットのプログラムをコンパイルし、実行可能にするための方法について説明しています。この文書は大きく 3 つの部分に分かれ、(1) ELF とは何か、アップグレードすべきか否か、(2) どのように ELF へアップグレードするか、(3)アップグレードしたら何ができるようになるか、について論じています。 </abstract> <toc> <sect> ELF とは何か？簡単な紹介 ELF(Executable and Linking Format) とは元々 USL(Unix System Laboratries) で開発されたバイナリファイルのフォーマット形式のひとつで、現在では Solaris と System V Release 4 が採用しています。Linux が今まで使っていた a.out 形式に比べてずっと柔軟性に富むので、去年、 GCC と C ライブラリの開発者たちは、Linux でも標準のバイナリフォーマットを ELF にすることに決め、ELF への移行を開始しました。「ずっと柔軟性に富む」というのは、平均的なアプリケーションプログラマにとって次の 2 つの利点があります。 <itemize> <item> ELF 形式を使うと共有ライブラリがずっと簡単に作れます。たいてい、すべてのオブジェクトファイルを -fPIC オプションを付けてコンパイルして、以下のようにリンクするだけですみます。 <tscreen><verb> gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o </verb></tscreen> ちょっと複雑に見えるかも知れませんが、a.out フォーマットで共有ライブラリを作るのに比べると、ずっと簡単になっています。a.out フォーマットで共有ライブラリを作る場合、ライブラリに将来必要になるであろう全てのデータについて、そのアドレススペースを確保しておく必要があります。そして、そのアドレススペースが他の人が作っているライブラリと競合しないように登録しておかねばなりませんでした(このあたりの話は <url url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.16.tar.gz"> の 20 ページくらいのドキュメントに詳しく書いてあります) <item> 動的ローディング(プログラムが実行時に必要なモジュールをロードすること)がずっと簡単にできる。Perl 5 と Python がこの機能を使っているプログラムの代表例です。この機能を super-fast MUD に使おう、というアイデアも出されています。この場合、追加するコードは別にコンパイルしてモジュール化しておき、実行しているプログラムを終了・再起動しなくてもモジュールをロードすることで新しい機能を追加することを目指しています。 </itemize> ELF を使うと少し遅くなる、という反論もあります。議論を聞いていると、2% から 5% くらい遅くなるらしいのですが、私の知っている限りでは、きちんとテストした人はいないようです。もし両者を比較しているテストを御存知ならば、ぜひ私に教えてください。遅くなる原因は ELF のライブラリコードがポジションインデペンデント(コンパイル時の <tt>-fPIC</tt> オプション)になっているからで、オフセットを記憶するためにレジスタが 1 つ使われるので、その分変数を記憶しておくレジスタが減るためです。特に 80x86 CPU では、汎用レジスタが少ないために影響が出やすいようです。 <sect1> ELF とは何ではないか ELF にするとどうなるかについて、多くの人が誤解している点があります。 <descrip> <tag>ELF にしても、SVR4 や Solaris のプログラムが動くわけではありません</tag>  確かに、バイナリを入れている「器」は SVR4 が使っているものと同じですが、だからといって SVR4 のプログラムが ELF を使えば突然 Linux で利用可能になるわけではありません。この関係はプログラムとディスクフォーマットによく似ています。つまり、Linux のプログラムを MSDOS や Minix 形式のディスクに保存したり、MSDOS や Minix のプログラムを Linux の形式のディスクに保存することは可能ですが、だからといって、それぞれのシステムが他のシステムのプログラムを動かせるわけではありません。SVR4 は Linux とは異なるシステムコールの使い方をしていますし、同じシステムコールでもその意味が違っていたり、違う番号に割りあてられていたりします。 <tag>ELF を使えば、プログラムが小さくなるわけでも速くなるわけでもありません</tag>  多くのプログラムの間で共通するコードをまとめて共有ライブラリを作ることが簡単になったおかげで、積極的にライブラリ化することでバイナリコードのサイズを小さくすることはできるかも知れませんけど。一般的に言って、同じコンパイラオプションを使って、出来たバイナリが a.out に比べて小さくなった場合、単なる偶然かコンパイラのバージョンが違っているせいでしょう。もし「速くなった」なら、ちょっとびっくりします。もっとも、バイナリが(簡単に作れる共有ライブラリを使って)小さくなったなら、スワッピングも少なくなるし、キャッシュに使える領域も広くなるので速くなるかも知れません。  <tag/全てのバイナリを入れ変える必要はありません/ ここに書いてある手順にしたがえば、ELF と a.out の双方をコンパイルして動かすことのできるシステムを作ることが可能です。将来リリースされるプログラムは ELF 用にコンパイルされているはずですが、これもコマンドラインのスイッチで変更可能です。もし ELF と a.out のプログラムを同時に動かそうとするならば、メモリを多少浪費することになります。また、C ライブラリも ELF 用と a.out 用の 2 種をインストールしておく必要があります。もっとも、 6MB のメモリで普通に使うかぎり、ELF と a.out が並存することによるスピードの低下には気づかない、という報告も聞いています(8Mb だと、もっと気づかないでしょう)ので、あまり気にする必要はないでしょう。だって、普段から Emacs や静的リンクされた Mosaic/Netscape のような膨大なメモリを食うプログラムを使っているでしょ :-) <tag/ELF はトールキンとも Pratchett とも、Keebler とも、神話学とも関係ありません/ 少なくとも、この文脈においては、、と言っておけば充分でしょう。 </descrip> <sect1> なぜ ELF へ移行すべき(すべきでない)か ELF を使えるようにシステムをアップグレードするのには、主に 2 つの理由があります：まず第一に、上述したようにプログラムがずっと柔軟にできること。第二に、第一とも関連しますが、だれもが ELF へ移行しようとしているから。将来の C ライブラリや GCC は ELF 用のみがリリースされますし、それ以外のプログラムの開発者たちも ELF の方へ進むはずです。対称性にとってうれしいことに、現時点では ELF へ移行しない方がいいのにも 2 つの理由があります。第一に、ELF はまだ開発の途中にあることです。いくかのパッケージ(カーネルを含め)は、ELF としてコンパイルするためにパッチが必要ですし、まだまだバグも残っているでしょう。例えば、Linus 自身が ELF に乗りかえるまで待つ、というのも一つの手です。 [訳注：linux 1.3.7 で kernel の ELF 化のパッチが正式に採用されました。1.3.7 以降のカーネルでは make config の際にカーネルを ELF 化するかどうかの選択が可能です。] 二つ目の理由は、ここに記してあるインストールの手順は比較的簡単な作業ですが(新しいソフトウェアをダウンロードする時間を除けば、一時間もあれば充分でしょう)、それぞれの段階でもしエラーが起きればシステムの起動が不可能になることです。共有ライブラリをバージョンアップする必然性がなく、 <tt>ldconfig</tt> や <tt>ldd</tt> といったコマンドに悩まされてもいないなら、ELF で固めたディストリビューションが出るまで待って、バックアップを取った上で ELF 版の linux を再インストールし、必要な部分のみ戻す方がいいかも知れません。その上で、(ダメになってもいい機械を使って)この文書を読んで、勉強してみるのもいいかも知れません。それでもやりますか？ <sect> インストール <sect1> 背景 ここに示す移行手順の目的は、a.out と ELF の双方をコンパイルして動かすことのできるシステムを構築することです。そのためには双方のプログラムが適切な共有ライブラリを見つけられなければなりません。このためには、他のいくつかのシステムがやっているように、単純に `<tt>/lib</tt> と <tt>/usr/lib</tt> そしてコンパイル時に指定されたディレクトリを全て探す' という方法よりも多少なりともスマートな方法が必要です。 linux でライブラリを探すのに使われるプログラムは <tt>/lib/ld.so</tt> です。コンパイラもリンカも出力するプログラムにはライブラリへの絶対パスは埋めこみません。その代りに、必要なライブラリ名と <tt>ld.so</tt> への絶対パスを埋めこんでおき、実行時に <tt>ld.so</tt> に適切なライブラリを選択させるようにしています。これがきわめて重要な機能になります -- すなわち、<tt>ld.so</tt> にライブラリを探すべき新しいディレクトリを正しく教えてやれば、プログラムをコンパイルしなおさなくても ライブラリを別のディレクトリへ移動させることが可能だ、ということです。この点が、以下に示すディレクトリの入れかえ操作の鍵になります。上記から導かれる結論として、<tt>ld.so</tt> を削除したり移動させたりすれば、動的リンクを使っているプログラムは全て機能しなくなる、ということがわかります。これは良くないこと(Bad Thing)である、と一般に考えられています。 ELF には ELF 用の動的ローダーが用意されています。これは <tt>/lib/ld-linux.so.1</tt> で、ELF プログラムに対して <tt/ld.so/ とまったく同じ機能を果します。<tt/ld-linux.so.1/ も a.out 用の <tt/ld.so/ と同じ設定ファイルとプログラム(<tt/ldd/, <tt/ldconfig/, <tt>/etc/ld.so.conf</tt>)を利用します。ですから、基本的な計画としては、ELF 用の開発環境(コンパイラ、インクルードファイル、ライブラリ)を、今 a.out 用の環境がある <tt>/usr/{bin,lib,include}</tt> に置き、a.out 用の環境を <tt>/usr/i486-linuxaout/{bin,lib,include}</tt> に移す、ということになります。<tt>/etc/ld.so.conf</tt> にライブラリが見つかるはずの場所を全て書いておけば、<tt>ldconfig</tt> は ELF と a.out を自動的に区別しますので、適切なライブラリを選択することができます。ライブラリを置くべき場所には多くの例外があります；詳しくは次の警告(caveats)の項を見てください。 <sect1> 始める前に --- 注意と警告 <itemize> <item> ELF 形式のバイナリフォーマットを使うには 1.1.52 より新しいカーネルが必要です。1.3.0 から 1.3.2 までのカーネルにはバグがあって ELF を使うことができません。開発用カーネルである 1.3 のシリーズを使ってるなら、最新のものを使うようにしてください。1.3.3 以降なら大丈夫、1.2.10 (現時点での最新の安定版カーネル)でも大丈夫です。 <item> Slackware のレスキューディスクのような boot/root ディスクを用意しておきましょう。多分必要ないでしょうが、もし必要になってしまった時に用意してなければ、地団駄を踏むはめになります。 <item> <tt>/usr</tt> や <tt>/usr/lib</tt> を <tt>/</tt>パーティションとは違うパーティションに取っている場合は特に注意してください。そのような場合、<tt>/bin</tt> と <tt>/sbin</tt> にあるプログラムが使っているライブラリをチェックして、それらをルートパーティションのどこか、例えば <tt>/lib-aout</tt>、に置いておく必要があります。この点に関しては後に適切なところでもう一度触れることにします。  <item> もし、ELF の開発を追いかけていたなら、<tt>/lib/elf</tt> に ELF 用のライブラリ(通常は libc.so.4 など)があるかも知れません。これらのライブラリを使うアプリケーションは再コンパイルする必要があります。その上でこのディレクトリは削除しましょう。もはや<tt>/lib/elf</tt> ディレクトリは不要です。このディレクトリは ELF の開発時のためのもので、Slackware のインストール時の標準ディレクトリになるなんてことはないでしょう。  <item> いくつかの古いプログラムは <tt/ld.so/ を使っていません。ですから、それらの使っているライブラリは移動することができません。この点は問題になるかも知れないし、ならないかも知れません。<tt/ldd/ を使って、どういうライブラリを使っているのかチェックしてください。もし使っているのが <tt/libc.so.4/ と/あるいは <tt/libm.so.4/ だけならば、これらのライブラリは <tt>/lib</tt> に残されるので問題はありません。もし X 関連のライブラリで、shape や form についてのライブラリのみの場合も大丈夫です。 <tt>ld.so</tt> を使わないくらい古いプログラムでは、ずいぶん古いバージョンの X のライブラリを使うようにコンパイルされているはずなので、当時の X のライブラリのメジャー番号もディレクトリの位置も今のものとは違っていますから。もし動かせない a.out ライブラリと ELF ライブラリが同じバージョン番号で、同じ場所に必要な場合、ELF ライブラリをどこか別の場所に移して、そのディレクトリを <tt>/etc/ld.so.conf</tt> に書いておきます。  もし使っているシステムがきわめて古くて、ファイル名に日付が入っているような共有ライブラリを使っているなら、あなたは明らかに Linux God(tm) の一人であり、この点に関しては私に正しい方法を教えてくださいますようお願いします :-) 回答は、この HOWTO のタイトルにあるアドレスまで。 <item> 最近の Linux では `FSSTND(ファイルシステムスタンダード)' に従って標準的なファイルシステムは配置されるようになってきましたが、そうでないシステムもまだまだあることでしょう。もし以下の説明で `<tt>/sbin/</tt>何たら' を使うようになっているのに、自分のシステムには <tt>/sbin</tt> ディレクトリが無い場合、それらのプログラムは <tt>/bin</tt> か <tt>/etc</tt> にあるはずです。 </itemize> <sect1> 必要なものは、、、 以下のパッケージは、<url url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/"> や <url url="ftp://sunsite.unc.edu/pub/Linux/GCC/"> から入手可能です。両サイトとも多くの場所にミラーされていますので、可能なかぎり近くにあるミラーサイト[日本ならば<url url="ftp://ftp.iij.ad.jp/pub/linux/sunsite/GCC/"> や <url url="ftp://ftp.spin.ad.jp/pub/linux/sunsite.unc.edu/GCC/"> など ] から探してください。その方があなたにとっても、みんなに取っても結局速く入手できることになります。以下に示すパッケージ(リストにあがっているバージョンかより新しいもの)が必要です。これらをダウンロードして、それぞれに附属のリリースノートを読んでみてください：リリースノートはたいてい <tt/release./<em/packagename/ という名前になっています。以下に示しているバージョンよりも新しいバージョンを入手した場合、必ずリリースノートに目を通してください。それら新しいバージョンではインストールの方法が変っているかも知れません。 <itemize> <item> <tt/ld.so-1.7.3.tar.gz/ --- 新しい動的リンカ <item> <tt/libc-5.0.9.bin.tar.gz/ --- ELF 形式の共有ライブラリの実行イメージで、C 用のライブラリとその仲間たち(m(数学ライブラリ), termcap, gdbm などなど)と対応する静的ライブラリ、これらを使ってプログラムをコンパイルするのに必要なインクルードファイルなどが入っています。 <item> <tt/gcc-2.7.0.bin.tar.gz/ --- ELF 対応の C コンパイラ。新しいディレクトリ・レイアウトを理解する a.out 対応の C コンパイラも入っています。 <item> <tt/binutils-2.5.2l.17.bin.tar.gz/ --- Linux 用にパッチをあてた GNU のバイナリ操作用プログラム。<tt/gas/, <tt/ld/, <tt/strings/ などが入っています。C コンパイラが機能するためには必須のプログラムです。 </itemize> <sect1> ファイルシステムの再構成 えーっと、あらかじめ注意しておきますが、以下で私が `削除する' と言ったら、自動的に `バックアップしてから削除する' と読みかえてください :-)なお、これらの指示は ELF で苦しんだことの無い人々向けのものです。すでに苦しんだことのある人は、適当に読み換えるに充分な知性を備えていることでしょうから。さあ始めましょう。 <enum> <item> HDD を <tt>/</tt> パーティションと <tt>/usr</tt> パーティションに分けている場合、多少の注意が必要です。起動時に <tt>/usr</tt> がマウントされる以前に動くプログラムを全てチェックするか <tt>/usr</tt> が読み出せなくなったらどうなるか試してみてください。そして、それらのプログラムが必要とするライブラリは <tt>/lib-aout</tt> に置きます。実はそれほど難しい話ではありません。単に、 <tscreen><verb> $ ldd /sbin/* /bin/* /etc/* >/tmp/list.txt </verb></tscreen> とやって、<tt>/tmp/list.txt</tt> を調べ、実行可能プログラムではないファイルについてのエラーは無視し、どのライブラリが使われているかメモしておきます。それらのライブラリがルートパーティションに必要となるライブラリです。このリストは保存しておきましょう。 <item>a.out 関係のファイルを移すための新しいディレクトリを作ります。 <tscreen><code> mkdir -p /usr/i486-linuxaout/bin mkdir -p /usr/i486-linuxaout/include mkdir -p /usr/i486-linuxaout/lib mkdir /lib-aout </code></tscreen> <item> ソースコードを置いているディレクトリで、動的リンカ <tt/ld.so-1.7.3/ パッケージを展開して、展開された直後の <tt>ld.so-1.7.3/instldso.sh</tt> スクリプトを読んでみましょう。もし、本当に標準的なシステムを使っているなら、<tt>sh instldso.sh</tt> を実行するだけでインストールすることもできますが、もし何か標準的でないものを使っているなら、手動でインストールする必要があります。`何か標準的でないもの'とは、、 <itemize> <item> シェルとして zsh を使っている(zsh のあるバージョンでは <tt/$VERSION/ という変数を定義しており、それが <tt/instldso.sh/ を混乱させます) <item> <tt>/lib/elf</tt> から <tt>/lib</tt> へシンボリックリンクを張っている (こうすべき理由はないのですが、もし ELF の開発を追いかけていたなら、こうしているかも知れません) </itemize> などです。 <tt>/etc/ld.so.conf</tt> を修正して、<tt>/usr/i486-linuxaout/lib</tt> を加え(必要ならば <tt>/lib-aout</tt> も加え)、<tt>/sbin/ldconfig -v </tt> を再実行して、新しいディレクトリを探しているかチェックします。 <item> libc と libm 以外のすべての a.out 形式のライブラリを探し出し、 <tt>/usr/*/lib</tt> から <tt>/usr/i486-linuxaout/lib</tt> か <tt>/lib-aout</tt> へ移します。<tt>/lib/ld.so</tt> は動かしたり、削除したり、その他一切いじってはいけません！一つのパーティションしか切っていない人なら、以下のコマンドで必要な作業の大部分がまかなえるはずです。 [訳注：以下の mv [ lib*.so* except for libc.so* and libm.so* ] /usr/i486-linuxaout/lib の部分は libc.so* と libm.so* 以外の lib*.so* を移動させる、という意味です。zsh だと似たような構文で実行できるそうですが、(t)csh, bash では手動で移動させる必要があると思います ] <tscreen><code> cd /lib mv *.o *.a *.sa /usr/i486-linuxaout/lib mv [ lib*.so* except for libc.so* and libm.so* ] /usr/i486-linuxaout/lib cd /usr/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib cd /usr/X11R6/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib cd /usr/local/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib </code></tscreen> <tt>/lib</tt> にある <tt>libc.so*</tt> と <tt/libm.so*/、<tt/ld.so/ 以外の、上記の各ディレクトリにある全てのライブラリファイルとオブジェクトファイル(<tt/*.o/) を移動させるまで、次に進んではいけません。 <tt/libc.so*/ と <tt/libm.so*/ は古いプログラムを動かすのに必要で <tt/ld.so/ は全てのプログラムを動かすためにまだ必要です。 <item> もし <tt>/usr/lib/ldscripts</tt> ディレクトリがあれば削除します。 <item> <tt>/usr/bin</tt> にある(<tt/ld86/ と <tt/as86/ 以外の)全ての <tt/ld/ と <tt/as/ のコピーを削除します。 <item> あるバージョンの GNU tar はシンボリックリンクされたファイルを扱う際に問題が生じることが知られています。そのため、libc のイメージファイルをインストールする前に、/usr/include へ行っていくつかのファイルを削除する必要があるかも知れません。  これは面倒くさい仕事ですが、<tt>/usr/include</tt> にのみインストールされ、対応する C ライブラリがないパッケージ(例えば ncurses) もいくつかあるので仕方ありません。まず /usr/include 以下をバックアップして、<tt>tar tzf</tt> して、あらかじめどういうファイルが入っているか確認しましょう。実際にファイルが書きこまれるディレクトリを削除した上で、 libc-5.0.9.bin.tar.gz をルートディレクトリから展開します。 <item> 以上で、ELF の実行形式を動かすために必要なファイルを全てインストールできました。医学の専門家によると、VDU ワーカーは定期的に休憩を取ってスクリーンの前から離れるべきだそうです。ちょうどいいタイミングですから、ここで一休みしましょう。 <item> さぁ、いよいよ ELF プログラムをインストールします。まず binutuils パッケージをインストールします。<tt> tar -xvzf binutils-2.5.2l.17.bin.tar.gz -C /</tt> とするのが最善の方法の一つです。 <item> <tt>/usr/lib/gcc-lib/{i486-linux, i486-linuxelf, i486-linuxaout}/</tt> 以下にあるファイルをバックアップした上で削除します。そして、gcc-2.7.0.tar.gz をルートディレクトリから展開します。 </enum> これで<bf>お終い！</bf> 以下に簡単なテスト法を示します。 <tscreen><code> $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs gcc version 2.7.0 $ gcc -v -b i486-linuxaout Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs gcc version 2.7.0 $ ld -V ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11) Supported emulations: elf_i386 i386linux i386coff </code></tscreen> 次は、伝統的な ``Hello, world'' プログラムを試してみましょう。オプション無しの gcc だけでコンパイルしたり -b i486-linuxaout オプションを付けてコンパイルしたりして、a.out と ELF の両コンパイラが正しく設定されているかチェックしてください。 <tscreen><code> $ cat >hello.c main() { printf("hello, world\n"); } ^D $ gcc -o hello hello.c $ file hello hello: ELF 32-bit LSB executable i386 (386 and up) Version 1 $ ./hello hello, world $ gcc -o hello -b i486-linuxaout hello.c $ file hello hello: Linux/i386 demand-paged executable (QMAGIC) not stripped $ ./hello hello, world </code></tscreen> <sect1> よくあるエラー この節では、皆さんから寄せられた問題を集めようと思っています。あらかじめ連絡していただければ、お名前は公表しません :-) <descrip> <tag><tt> no such file or directory: /usr/bin/gcc </tt></tag> <tt>/usr/bin/gcc</tt> はちゃんとありますよね？その場合、ELF 用の動的ローダーである <tt>/lib/ld-linux.so.1</tt> がインストールされていないか、何らかの理由で読み出せなくなっています。インストールするか、前節の step 3 のあたりをチェックしてください。 <tag><tt> not a ZMAGIC file, skipping </tt></tag> このエラーメッセージは <tt>ldconfig</tt> からのものです。古いバージョンの ld.so を使っているようなので、新しいものを入手してください。前節の step 3 をもういちど見てください。 <tag><tt> bad address </tt></tag> ELF フォーマットのプログラムが全てこのエラーになるときは 1.3.0 から 1.3.3 までのカーネルを使っているはずです。1.3.3 以上にアップグレードするか 1.2.x を使いましょう。 </descrip> <sect> ELF でプログラムを作るには <sect1> 普通のプログラムの場合 ELF 形式でプログラムを作るには <tt>gcc</tt> を普通に使うだけです。 a.out 形式でコンパイルするには <tt>gcc -b i486-linuxaout</tt> としてください。  そろそろ ``もし a.out 形式のコンパイラがデフォルトで生成する実行プログラムの名前が <tt>a.out</tt> なら、ELF コンパイラがデフォルトで生成するプログラムの名前は何と言うの？''という問いに答えましょう。やっぱり <tt>a.out</tt> 、というのが答えなんです。残念でしたか <tt> :-)</tt> <sect1> ライブラリの作り方 共有ライブラリとして libfoo.so を作る基本的な手順は以下の通りです。 <tscreen><code> $ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o $ ln -s libfoo.so.1.0 libfoo.so.1 $ ln -s libfoo.so.1 libfoo.so $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH </code></tscreen> これで <tt>libfoo.so.1.0</tt> と言う共有ライブラリができ、ld が識別すべきリンク(<tt>libfoo.so</tt>) も張られ、動的リンカも見つけることができます(<tt>libfoo.so.1</tt>)。テストのために、このプログラムのあるディレクトリを <tt/LD_LIBRARY_PATH/ に追加しています。もし作った共有ライブラリがちゃんと動くようなら、適切な場所、例えば <tt>/usr/local/lib</tt> にでも移して、必要なリンクを張りましょう。 <tt>libfoo.so</tt> が <tt>libfoo.so.1</tt> を指すようにリンクを張って、マイナーバージョンナンバーが変わる度に update しなくても済むようにしておきましょう。<tt/libfoo.so.1/ から <tt/libfoo.so.1.0/ へのリンクは <tt>ldconfig</tt> によって、たいていのシステムでは起動時に更新されるようにっています。 <tscreen><code> $ su # cp libfoo.so.1.0 /usr/local/lib # /sbin/ldconfig # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so ) </code></tscreen>  <sect1> 動的ローディングを使うプログラム この問題については H J Lu 作の「ELF プログラミングドキュメント」と ld.so パッケージに附属の <tt>dlopen(3)</tt> のマニュアルページにくわしく解説してあります。ここでは簡単な例を示すに留めましょう。以下のプログラムを <tt>-ldl</tt> オプションを付けてリンクしてみてください。 <tscreen><code> #include <dlfcn.h> #include <stdio.h> main() { void *libc; void (*printf_call)(); if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY)) { printf_call=dlsym(libc,"printf"); (*printf_call)("hello, world\n"); } } </code></tscreen> <sect1> デバッグ  お手持ちの <tt/gdb/ は ELF プログラムに対しても特に変更なしで動くはずです(たいていの場合)。しかし、tsx-11 の <tt/GCC/ディレクトリにある新しいバージョンの gdb は動的ローディングにも対応し、ELF 形式のコアにも対応しているそうです。しかしながら、この文書を書いている時点では、ELF プログラムがコアダンプするためにはカーネルにパッチを当てる必要があります。問題が多少専門的になるので、この文書ではそこまで扱いません。 <sect> パッチとバイナリ 以上で ELF 形式のプログラムをコンパイルして動かすのに必要な作業は全てすみました。お好みならここで読むのをやめても結構です。美的観点(neatness)やメモリの使用を最小限にするために、既存のプログラムを ELF 形式で再コンパイルしたくなるかも知れません。ほとんどのエンドユーザー向けのプログラムはごく簡単にコンパイルできます；しかし、いくつかのプログラムでは a.out 環境に強く依存しているため、以下のようなエラーを出すことがあります。 <itemize> <item>  アセンブラのアンダスコア(<tt/_/)の使いかたの違い：a.out 形式の実行ファイルでは、外部の関数や変数のラベルには <tt/_ / が頭に付いていました；一方、ELF 形式の実行ファイルにはアンダスコアが付きません。これは手書きのアセンブラコードを混ぜて使わないかぎり、特に問題にはなりません： <tt>_foo</tt> 形式のラベルをすべて <tt>foo</tt> に変換するか、あるいは (両方の環境でコンパイル可能にしたければ) <tt/EXTERNAL/ というマクロを定義して <tt/EXTERNAL(foo)/ という形にします。ここで <tt/EXTERNAL/ いうマクロは (<tt/__ELF__/ が定義されていれば) そのまま引数を返し、さもなくば <tt/_/ を前につけて引数を返すようなものです。 <item> libc5 と libc 4 の違い。例えば locale とのインタフェースが変更されています。 <item> アプリケーションやコンパイルの過程が、使用しているバイナリ形式に依存する場合 -- 例えば emacs では実行形式を作る際にメモリイメージをディスクへダンプするので、実行ファイルのフォーマットについての知識が必要になります。 <item> アプリケーション自身が共有ライブラリだったり、共有ライブラリを含む場合 (X11 が典型的な例)。これらについては ELF の方法で共有ライブラリを作るように(Makefile などを)変更しなければなりません。 </itemize> 以上を踏まえて、以下に示す 2 つのリストを作成しました。前者(アップグレード)は既に公式リリースが ELF に対応しているソフト(すなわち ELF 用にコンパイルするためには新しいバージョンを手に入れればいいもの)で、後者(パッチ) は第三者が出している ELF 用のパッチが必要なソフトです。 <sect1> アップグレード <itemize>  <item> <bf>dosemu</bf> 開発中のいくつかのバーション以外では(どのバージョンかは聞かないこと。linux-msdos のメーリングリストに参加してください)、 dosemu は ELF で動きます。Makefile をちょっといじる必要があります。 dosemu の最新バージョンは <url url="ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/"> にあります。 <item> <bf>Emacs</bf> Emacs はちょっと変ったやり方で作成されます。 Emacs はまず最小限の機能しか持たないバージョンを起動して、必要な lisp コードを読みこんだ上でディスクへダンプし、実行形式にしています。Emacs 19.29 は ELF 環境で起動されているかどうかを判断し、正しいやり方を自動的に選択します(XEmacs については後者のリストを見てください) <item> <bf>perl 5.001</bf> perl 5.001 と ``公式・非公式'' パッチ群は特に変更しなくても ELF システムでコンパイルでき、動的ローディングにも対応しています。perl に対する各種のパッチは <tt>ftp.metronet.com</tt> か <tt>ftp.wpi.edu </tt>から入手できます。 <item> <bf>util-linux 2.2</bf> に入っている <tt/cal/ プログラムは動きません。2.4 以降のもの(<url url="ftp://tsx-11.mit.edu/pub/linux/packages/utils" name="version 2.4">)にアップグレードしてください。 <item> <bf>XFree86</bf> XFree86 は多数の共有ライブラリを含むので、ELF ライブラリを作るためには多少の変更が必要としても驚くにはあたりません。完全なバイナリディストリビューションが以下のサイトから入手可能です。 <url url="ftp://ftp.beckman.uiuc.edu/pub/linux/X11/"> あるいは <url url="ftp://ftp.mcc.ac.uk/pub/linux/ALPHA/XFree86-3.1.1-ELF-3/">。  </itemize> <sect1> パッチ <itemize> <item> <bf>e2fsutils</bf> Second Extended File System 用のユーティリティを共有ライブラリとしてコンパイルするには、<url url="http://sable.ox.ac.uk/~jo95004/patches/e2fsutils.diff"> にあるパッチが必要です。e2fs の作者 Remy Card によると、``この ELF 用のパッチは多分 e2fsck と関連ツールの次のバージョンには含まれるはず'' ということです。 <item> <bf>file</bf> そのままでも動きますが、<url url="http://sable.ox.ac.uk/~jo95004/patches/file.diff"> のパッチを当てれば ELF バイナリの stripped や mixed-endian も識別することが可能になります。 <item> <bf>カーネルそのもの</bf> カーネルについては 2 つの論点があります。(a) ELF バイナリを動かすことが可能かどうか(この点については、カーネルのコンパイル時(<tt/make config/ 時)に ``Kernel support for ELF binaries'' に `Y' と答えれば可能です)、(b)カーネルを ELF 形式でコンパイルできるかどうか。(b)については一般的には `no' です。ですから、カーネルのコンパイル時には a.out 形式を使うように Makefile に修正を加える必要があります。Makefile の<tt>CC</tt> と <tt>LD</tt> の定義を以下のようにしてください。 <tscreen><code> LD =ld -m i386linux CC =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include </code></tscreen> (b) に対する別の解として、H J Lu のパッチを当てれば、カーネルを ELF 形式でコンパイルするこのも可能です(このパッチで ELF 形式のプログラムに core dump させることも可能になります)。このパッチはごく近い将来に 1.3 のカーネルに取りこまれるはずですが、<tt/ps/ とそれに関連するユーティリティ用に <tt/psupdate/ プログラムが namelist をサポートするように hack する必要があります。 [訳注：上でも書きましたが、1.3.7 以降のカーネルでは ELF 化パッチが公式リリースに取りこまれました。カーネルを ELF で作成するか否かは <tt>make config</tt> 時に指定できます] <item> <bf>SVGATextMode</bf> には簡単な調整が必要です。以下に示す diff を切り出して patch として当てるか、ファイルを直接手で修正してください。 <tscreen><code> --- SVGATextMode-0.7.orig/XFREE/os-support/assyntax.h Sun Feb 26 18:58:15 1995 +++ SVGATextMode-0.7/XFREE/os-support/assyntax.h Thu Mar 30 07:52:03 1995 @@ -211,7 +211,7 @@ #endif /* ACK_ASSEMBLER */ -#if (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) +#if (defined (__ELF__) || defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) #define GLNAME(a) a #else #define GLNAME(a) CONCAT(_,a) </code></tscreen> <item> <bf/XEmacs/ XEmacs 19.11 に <url url="http://sable.ox.ac.uk/~jo95004/patches/xemacs.diff"> のパッチをあててみてください。 </itemize> <sect> その他の情報 <itemize> <item> 自分からは投稿しなくても linux-gcc のメーリングリストに参加することは、 ELF 化がどのように進行しているのかを知るための最善の方法です。忘れないで欲しいのですが、このメーリングリストは Usenet とは違い、開発者の連絡用のものであり、開発上の問題以外を質問する場ではありません。メーリングリストへの参加方法は <tt>help</tt> と書いたメールを <tt>majordomo@vger.rutgers.edu</tt> へ送ってください。 <item> Bobby Shmit が運営している <url url="http://www.intac.com/~cully/elf.html" name="ELF upgrade experience"> web ページも参考になるでしょう。 <item> GCC-FAQ(<url url="ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-FAQ.html" name="GCC-FAQ">) には ELF についてのより一般的な開発上の情報と技術的な詳細が説明されています。 <item> tsx-11(<url url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz" name="tsx-11">) には ELF のフォーマットを解説した ELF.doc.tar.gz があります。この文書が ELF のフォーマットを理解し、直接バイナリオブジェクトを扱う類いのプログラムを書き直したりデバッグするのに最善の資料でしょう。 <item> H J Lu がまとめた ELF に関するドキュメントが<url name="ELF: From The Programmer's Perspective" url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz">にあります。H J Lu はプログラマの視点から有益で詳細な ELF に関するプログラミング情報をまとめています。もし Latex が使えないなら、Postscirpt 版もあります。 <item> <tt/ld.so/ パッケージに附属の <tt/dlopen(3)/ のマニュアルページ </itemize> <sect> Copyright This document is copyright (C) 1995 Daniel Barlow <tt/<daniel.barlow@sjc.ox.ac.uk>/ It may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. この文書の著作権(C)は Daniel Barlow<tt/<daniel.barlow@sjc.ox.ac.uk>/ が所有しています。この著作権表示が全てのコピーに残されるかぎり、あらゆる物理的、電子的媒体を用いて、全体、あるいは部分的にコピー、配布することが可能です。商業的な配布も可能で、奨励します；しかし、商業的に利用する場合は連絡してくれることを望みます。 All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. 翻訳やこの文書から派生した仕事、あるいはあらゆる種類の Linux HOWTO ドキュメントと共に集積する仕事にもこの著作権は適用されます。すなわち、 HOWTO から派生した文書に対して配布に制限を加えることはできません。このルールに対する例外も一定の条件の元で許可されます。下記に示す Linux HOWTO のコーディネーターに連絡してください。 In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. 簡単に言うと、我々は可能な限りのチャンネルを通じてここに示した情報を普及させたいと願っています。しかしながら HOWTO 文書に著作権を付けているのは、HOWTO を再配布する計画について報せて欲しいと思っているからです。 If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator, at <tt/gregh@sunsite.unc.edu/ via email, or at +1 404 853 9989. 質問があれば、Linux HOWTO のコーディネーターである Greg Hankins に連絡してください。e-mail のアドレスは <tt/gregh@sunsite.unc.edu/ 、電話なら +1 404 853 9989 です。 </article>