「とりあえず make しよう」(1) 第三版

ここで、オブジェクトは機械毎に違うし、基盤となる OS によっても異なります。仮にパソコンの世界ならば PC98, FM-Towns, IBM-PC, Mac, X68000, AMIGA … といま挙げただけでもハードの分類だけで沢山ありますし、OS によっても MS-DOS, OS-9, System7, 386BSD, Linux … ハードウェアの違いはある程度は中にある MPU と OS が同じならばある程度吸収してくれるとはいえ、そうだとしても沢山の分類があります。

ここで仮にアセンブラしかなかったならば、それぞれの OS、それぞれの MPU で全く違う書き方をしなければならない上に複雑な計算をやらせるとしたら … 考えただけで脳ミソが爆発してしまいます。

こういった「ハード間の差異」や「記述の複雑さ」を乗り越えるためにインタプリタ [2] やコンパイラが色々な仕様 (BASIC, PASCAL, FORTRAN, そして C 等) で作られ、その外側の、OS 寄りな部分での差異をライブラリ [3] が埋めているのです。

ここで、UN*X の世界に目を向けて見ましょう。大型のスーパーコンピュータから WS、そして今貴方が使っている Towns や IBM-PC と言ったパソコンまで雑多なハード仕様と MPU に細かく違う OS 仕様が混在しています。

これらの間で、同じかそれに近い書き方でプログラムを書くことが出来れば、ある機械で書き、動かしたプログラムの成果の殆どを全く違う機械で実現する事が出来ます又、その事によって、ユーザとして使ってる人達がプログラムを書く労力を激減する事が出来るのです。

従って、UN*X では、MS-DOS 等と違い、通常は C 等の高級言語によって書かれたソースコードの形で (フリーな) プログラムが流通しています。 [4]

1. コンパイラと make

　ソースコードで入手した物をコンパイルするには、それに適合しているコンパイラが必要になります。今貴方が使っている Towns や IBM-PC における Linux では、 gcc が標準の C 言語コンパイラとなっていますので、まずはそれをインストール [5] して下さい。

さて、これで C の知識のある人ならば、"HELLO WORLD" なんぞと表示させてニヤリとする所ですが、通常流通しているプログラムは個別にコンパイルしていたのではとても手間がかかってしまうし、作る側も虫取り (デバッグ：ミスを修正する) の手間がかかってしまうので、コンパイルを支援するツールが幾つも作られました。

その中でもポピュラーかつ強力なのが make ( Linux では GNU-make ) です。

これは、詳しくは C 言語の本を見て欲しいのですが (奥が深いので解説はしない)、ソースファイルとオブジェクトファイルを対応させておいて、オブジェクトが出来た後にソースが書き直されていたりしたならばコンパイルをやり直したり、特定の作業を行う様にする対応表 (バッチでもある) を Makefile 等と名付けられたファイルに書いておく事によって半自動でコンパイルを進ませてくれるツールです。

例えば、

Example 1. Makefile 例

  # Test.c は main.c と sub.c から成る
  #
  # ライブラリのあるパス
  LIBDIR = /usr/lib
  # ヘッダのあるパス
  HEADDIR = /usr/include
  # オブジェクト
  OBJS = main.o sub.o
  # ソース
  SRCS = main.c sub.c
  # 使うライブラリ
  LIBS = -lc -lg
  # 機種識別等やコンパイラ制御の為の、定義フラグ
  FLAGS = -O -DTONWS -Dlinux

  # まずは、実行形式の定義
  test: $(OBJS)
  　gcc -static -o test $(OBJS) -L$(LIBDIR) -l$(LIBS)

  # 次に、コンパイル
  # ターゲット: ソースと言う対応表を書いて、引っ掛かった物に対する処理を次の
  # 行に書く。
  # 下の場合、sub.c が sub.o が出来た後に書き換えられていたら、
  # gcc -c sub.c $(FLAGS) を実行して、sub.c をコンパイルする。
  #
  sub.o: sub.c
   gcc -c sub.c $(FLAGS)

  main.o: main.c
   gcc -c main.c $(FLAGS)

  # オマケ。
  clean:
   rm -fr $(OBJS) test

等とこれはイイカゲンな物 (架空の物) なのですが、こういった感じで書きます。この時、単に make とすればソースから test と言うオブジェクトが作られるし、make clean とすれば、オブジェクトを消してくれます。

その他、Bison (Yacc) やら Lint やら lex (Flex) やら色々とありますが、それは後学のタネにしましょう。(とりあえず、C の使い方だけでも身に付けないときつい物がある)

チェックポイント:
make の基本的な文法
C のマクロの書き方
機種や OS に依存している記述への対応、特に BSD 系か SYSV 系かでの判断
コンパイラへのオプションの書き方

2. 配付形態

　「なぜ、コンパイルが必要か」で私は「 UN*X の世界では通常ソース配付である。」と書きました。しかし、バラバラでは色々都合が悪いし、大きさもそのままでは電話代や課金がかさんで問題が出てきます。(その上、UN*X の世界ではバケツリレー的に通信してるので、他の端末に迷惑をかけると言う問題が生じる事も少なくない [6] 。)

そこで登場するのがアーカイバや圧縮ツールと言う物です。大まかに配付に於いて使われる形態は、

tar を使ってまとめる(圧縮せず)
tar でまとめた物を compress (gzip) で圧縮する
tar でまとめた物を LHa (LHarc) 等の圧縮機能付きアーカイバで圧縮する
LHa / UN*X 等の、UN*X 対応の圧縮機能付きアーカイバで圧縮する
zip を使って、LHa と同じ方法で圧縮する
shar を使って、ソースコードをそのまま一個にまとめる。この場合、圧縮やバイナリ化された物は送れない。

に大別されますが、"d" は普及の関係か、余り一般的ではありません。

又、アーカイブされた物を流すには、

テキストならば、そのまま流す
バイナリイメージを流す。これは ftp サイトや BBS 等で用いられる普通の方式
ish を使ってバイナリをテキスト化する (バイナリ化には ish を用いる)
uuencode を使ってテキスト化する (バイナリ化には uudecode を用いる)

"3" と "4" は、BBS やニュースグループでの書き込みで主に用いられます。

チェックポイント:
拡張子での配付形態の違い(（７）参照)

3. ライブラリ等の配置

少し、インストールに言及しましょう。まず、当然ながらインストーラなり手動なりで gcc を展開します。

gcc-2.5.8 が 1994/4/16 現在の Linux / Towns 標準の筈 [7] ですので、展開された gcc は以下の様な配置になってると思います。 (ここでは、FFMHOB での配付形態の物を zcat と tar を使って
zcat gcc-*.tgz | tar xvoof - -C /
等として解凍したと言う前提で話を進めますが、UNIX USER 誌や LASER 5 の CD-ROM でも、SLS や SLACKWARE のパッケージの中に入っていますので、そちらを持っている方はそちらがお得です:）

これ以外にも、各種のライブラリ (プログラム実行時もしくは作成時にリンクされる、最も OS 寄りの部分) を入手して /lib や /usr/lib に配置する必要があります。

1994/4/16 現在の Linux 向けの C ライブラリのリビジョンは 4.5.19 ですので、以下に示す三つをダウンロード ( 1.5 M はあります ^^; ) するか CD-ROM 等から導入します [8] 。

　libc-4.5.19.tar.gz :基本的なライブラリィ。実行のみの為の物が中心。　extra-4.5.19.tar.gz :プログラミングするには必要なライブラリ。　include-4.5.19.tar.gz :上の二つを gcc から使う為のヘッダ類。

lib をダウンした (もしくは持ってる CD-ROM の) ディレクトリィから

zcat libc-4.5.19.tar.gz | tar xvoof - -C / zcat extra-4.5.19.tar.gz | tar xvoof - -C / zcat include-4.5.19.tar.gz | tar xvoof - -C / ln -sf /lib/libc.so.4.5.19 /lib/libc.so.4.5 ln -sf /lib/libc.so.4.5 /lib/libc.so.4
　最低限、以上の操作が必要です。

これ以外に現在使っているバージョンの Linux のソースコードの一部が必要になります(具体的には、C のヘッダとして提供されてる部分)。そして、配置は、(自己流ですが、最低限の配置換えで済む)
/lib : ダイナミックリンクライブラリィ /usr/include : gcc の include /usr/include/linux , /usr/include/asm : Linux 側の include 　　　　　　　　　　　　　　　　　　　　(カーネルのソースコードの一部)
　これらは以下の様にして配置します。( /usr に gcc を解凍したとする)
ln -sf /usr/gcc-2.5.8/lib/gcc-lib/i486-linux/2.5.8/lib/* /usr/lib ln -sf /usr/gcc-2.5.8/lib/gcc-lib/i486-linux/2.5.8/lib/* /lib ln -sf /usr/gcc-2.5.8/include/* /usr/include ln -sf /usr/src/linux/include/* /usr/include

チェックポイント:
配付されている gcc のディレクトリィ配置構造の確認
シンボリックリンク (ln -sf) の使い方
Linux でのライブラリの配置構造

4. make する

＊＊コラム＊＊

今配付されているソフトの幾つかは configure なるシェルスクリプトを動かして半自動で Makefile や OS 依存情報を作成してくれる物があります (最近配付されてる GNU 系のソフトは殆どがそうです)。しかし、コンパイラや OS の細かい仕様の関係で必ずしも正確な物を作ってくれない場合が少なからずあります。そこで、単に configure → make するだけでなく、問題箇所を最適な形で修正する術を覚える必要があります。

＊＊コラム終わり＊＊

4.1. 変更の必要が最低限なもの

では、ここでは殆ど変更無で動く物を取り上げましょう。例として、FUNIX にある fu を make してみましょう。

まず、MS-DOS 上の、Linux からアクセス出来る区画にダウンロードしてきた fu を転送します (勿論 FD にバックアップを取って置くこと)。次に、多分貴方が手にしているバージョンの fu の配付形態は (c) であると思います。そこで、LHa を使ってこれを解凍すると、fu***.tar と言う ( *** はバージョン。現在は 302 が最新だと思う…。以下 fu302 であると仮定)ファイルが出て来るはずです。

そして、Linux を起動。そして、Linux でのソースコードのルート (が仮に /usr/src だと定義する) に tar を使って MS-DOS 区画 (ここでは、/mnt/dos/buff と仮定) にある fu302.tar を転送・展開します。

具体的には、
cd /usr/src tar xvf fu302.tar
と言う感じです。

そうすると、./fu302 (/usr/src/fu302) にソースコード等が展開されてる筈です。ついでに、
cd fu302
と打ち込んでディレクトリを移動しましょう。

ここで、まずマニュアル (fu.doc.euc) を読みます(笑)。(日本語なのでわかると思う)
more fu.euc.doc
less がある人はless を使いましょう:-)

次に機種規定を HP9000 に書き換えます [9]。 machine.h をエディタで以下のように書き換えます。以下、＞の後に来る行を、次の様に書き換えます。
＞#define H2050 1 #define H2050 0 ＞#define HP9000 0 #define HP9000 1

次に Makefile を HP9000 用の物に置き換えて、更に書き換えます。まず、
cp MakeHP9000 Makefile

貴方が好みのエディタを起動して、(念の為に) Makefile を書き換えます [10]。この Makefile の場合、# で始まる行はコメント扱いにされるので、打ち込まなくても結構です。
＞CFLAGS = CFALGS = -O6 -Dlinux -DTOWNS # 一応、念のために Linux であることと Towns であることを宣言しておく… # 一部ヘッダファイルが Linux かどうか等をチェックしているので。/lib/specs に # 記述して置いてある物に関しては付けなくても良い。(単なる保険) ＞gcc -s（中略）-lcurses gcc -s -L/usr/lib ${OBJFU} ${OBJSUB} ${OBJCOM} -o $@ -lcurses -ltermcap # ライブラリィを指定 (かなりデタラメ) した上に、シンボル情報を削除にした。 # トラブルが起きた場合に問題があるかも知れないが、シンボル情報は実行部分の # 何倍もスペースを喰うので、基本的かつデバッグを必要とする状況の物以外は要 # らないと思うが、どうでしょうか？ ## libjcurses.a (いわゆるペリカン curses) 等日本語を通す curses をお持ちの方 ## は、そちらをリンクする方がベターです:)

さて、ここまで済んだら make を始めます。
make
と打ち込んで後はエラーが出ないことを祈りつつ待ちましょう。(ここからがイバラの道なのですが… )

警告が出るかもしれませんが、それは無視してとりあえず出来ました。さて、試しに使って見ましょう。
./fu

使い勝手がいまいちだと思ったら、.setup.fu を使いやすい様に書き換えて再びホームディレクトリに複写 (マニュアル参照) します。

納得出来たら、ln -sf /usr/src/fu302/fu /usr/local/bin か cp ./fu /usr/local/bin としてすぐに実行出来るようにしましょう [11]。

# 尚、この版のリリースと前後して、源著作者から OK を頂いた上で gzip や zip を
# 使える様に改良した fu の差分を公表する予定です (現在、更なる改良中)。
# 期待しないでお待ち下さい:-)

4.2. Laser 5 の CD から引っ張ってくる

さて、この項では以前は GNU-CD2 から引っ張って来ていましたが、今は iso9660 フォーマットの CD-ROM でのファイル名の制限を克服するための RockRidge 形式 (別に名前の対応表を持って置いて、そちらの名前を参照する) が普及しているお蔭で sed 等を使ってスクリプトを書いたりなどする必要はなくなりつつあります。

一応、この項の最後に参考までに残して置きますので、古い CD-ROM から、 MS-DOS のテキストとして記述したソースコードを引っ張ってくる際に参考にして下さい。

今回は、minicom 等の端末から使う zmodem を取り上げます。Linux から各種 BBS (win.or.jp 等の、端末を一般に開放してる U*IX ホストも含む) にアクセスしてダウンロードやアップロードする際には必須のソフトです。

まず、CD-ROM を mount します。(/etc/fstab への登録を忘れずに:）) CD-ROM は /mnt/cdrom に mount されると言う前提で行きます。
mount /dev/cdrom # /etc/fstab を書き換えてない場合は、mount -t iso9660 /dev/cdrom /mnt/cdrom # 等としましょう。

次に、ソースコードを置くディレクトリィを作ります。但し、この作業は無くてもいい場合が多いです (/usr/local/src にディレクトリィを作る。と言う前提で行きます)。
mkdir /usr/local/src/rzsz

さて、解凍しましょう。
　cd /mnt/cdrom/OTHERS/#211:Communications/term/ zcat rzsz9202.tar.gz | tar xvoof - -C /usr/local/src/rzsz

次に、Makefile を変更します。これは変更の必要が最低限のものを読んで、なおかつ展開された Makefile や README 等を読めば分かると思いますし、rz/sz は無変更で makeしても動くので、宿題にします:-)

＊＊コラム＊＊
- 古い (もしくは MS-DOS 専用の) CD-ROM から転送する -

GNU-CD2 においては、"MS-DOS で読む" と言う制約から、ファイル名が 8 文字＋拡張子 3 文字以内に設定されています。　又、ファイルの属性 (ファイルがどういう物か示す… chmod で変えられる) も全く違いますし、もしもテキストが MS-DOS 仕様ならば、mstrip 等で余計な改行コードを消す必要があります。

そこで、"記録されてるファイルネームと本来の物との対応表を用意しておいて、 UN*X 上で復元する" と言う事を行うコマンドが、cdrname (Towns 版 Linux に添付。又、GNU-CD2 等にソースコードが収録されている) です。

例えば ish では、GNU-CD2 から /usr/src/ish にファイルを転送して、
mstrip * cd /usr/src/ish cdrname
　とすれば、ファイル名を復元してくれる筈です。しかし、CD-ROM から落とした場合には、最後に余計な. が付いて来る事があります。これはしょうがないので、 SED (Stream EDitor) 等を使って名前を変更した後で cdrname する必要があります。

以下、スクリプト。
#!/bin/sh ls *. | sed -n 's/$.$\.$/\mv & \1/p' | sh -

　さて、これでファイル名 (パス) が修復されました。次に、Makefile を Linux 向けに変更します(変更なしでも出来そうだが、保険をかけておく)。OS 依存情報を「5.1 変更の必要が最低限なもの」と同じように変えれば良いので、宿題にします。(^^) (但し、-ltermcap や -lcurses は必要ない。)

　さて、後は make 一発で実行形式が出来る筈です。

＊＊コラム終わり＊＊

4.3. カーネルを構築する (パッチの使い方)

ここでは、ダウンロードした Linux のソースに Towns 固有の機能を使わせる為の修正 (ここでは、これを「パッチ当て」と示す… もっと広い意味 (コラム参照) なんですが :-） ) を施して各種機能が使える Linux / Towns へとして行き、最終的にブートイメージ (とカーネル) を作り上げます。

＊コラム：patch とは？＊

ソースコードや文章の一部を変更すれば済む場合、その部分を指摘して修正要求をする方が経済的です。そこで生まれたのが、diff と patch です。詳しく言えば、修正前の文書 (複数指定可) と修正後の文書を比較して、違う行の指摘を行う形式の (又、新しいファイルがあれば、それも登録する) ファイルを diff によって作り、patch はそれを基に今配付されたり保存されてたりする古い文書を新しい物に変更して行くのです。

＊＊コラム終わり＊＊

さて、NIFTY の FFMHOB の Lib12 と FUNIX の Lib11 に収録されている、今最新版であるカーネルコード (大体は FUNIX にある IBM PC 向けの物を、Towns で動くようにした各種パッチが FFMHOB に収録されています… CD-ROM で配付されてる場合は、とりあえずそれ) でやって見ましょう:-)

ここでは、FUNIX Lib12 にある 1.00 のカーネルソースに FFMHOB Lib6 にある Towns 対応 β1 版パッチを当ててみます。カーネルソース自体を pl5 までアップグレードしないと β1 版パッチは当たらないので、注意しましょう。

まず、おおもとの Linux のカーネル (中心部) の元のコードを展開します。 [12] (/---/は、圧縮状態の元ファイルがあるディレクトリィ)
cd /usr/src zcat /---/linux100.tgz | tar xvoof -

　次に、予めダウンロードして/usr/srcに展開しておいたpatch1からpatch5迄を当てます。流通してる場所によって配布形態が違うので、ここでは展開について詳述しません [13]。
for i in patch#[1-5] ; do patch -p <$i ; done

　次に、Towns 対応にするためにパッチを当てます。
zcat /---/tlx105b1.tgz | tar xvf - cd linux patch -p <../tlx.100.5.b1

サテ、makeしましょう。まず、使うデバイスや機能等を設定します。（必ず README.towns を事前に読む事）
cd /usr/src/linux make config

　ここで出される質問に答えましょう。

次に、ヘッダ等の依存関係を読み込みます。カーネルと言う重要な物なので、特に必要です。
make depend

この時点で、makefile や config.h（場合によっては drivers/char/keyboard.map も）を変更しておきます。そして、make します。（386DX/16 で、最低一時間強はかかるので、買い物とか済ませるのも手です ^^;）
make

make が終了したならば、make の間に出た警告を一応無視して、"zImage" と言うファイル（これが、新しく出来たブートイメージ）名でdos 区画に転写します。 MS-DOS からの立ち上げを \liboot で行っているならば、
cp zImage /mnt/dos/liboot sync
　でＯＫです。

　そして、ドキュメントに従って新しく出来たデバイスを/devにmknodで登録します。その後、sync→rebootで一旦ＭＳ－ＤＯＳに戻ります。
sync reboot -h now
さて、ＭＳ－ＤＯＳから新しい Linux を起動してみましょう… いつもの様にカレントドライブとディレクトリィを動かし、dosboot2 します。但し、ここで、dosboot -i image …と指定していたのを、dosboot2 -i zImage…としないと古いデータで起動してしまうので注意注意。

チェックポイント:
MS-DOS 区画と Linux 区画とのコミュニケーション
vi, stevie や mule, nemacs 等 UN*X のエディタの使い方
Makefile (make) の文法
C での機種・OS 依存部分の解析とそれを指定するのに必要とされる情報の記述
patch -p　の使い方
diff　の使い方

5. あとがき

最初は「苦戦日記」調の物を予定していたのですが、全くアホな事に、中途半端なチュートリアルもどきになってしまいました…

この文は収録されるかもしれない Linux-CD ではなくて、Nifty からダウンロードされる人達を対象にしてしまってるので、make するの多くは無意味な情報になってしまった様な感じで更に情け無い…

今回は X に関連した事項やライブラリィの作成等については省きました。続きを出せれば、そこで触れる事になるでしょう。ここで出しても良かったのかもしれませんが、私自身の知識を越えてるので… 何方か、libc や Xlib に関する具体的仕様を記述した書物 (出来れば日本語で安い物) 等についてお教え願います…

ともあれ、これが「到達目標」なのではなく、全く別の「目標」を目指す為の道標となり、又、同じ様に苦戦されてる人達の灯となることを祈っております…

　　１９９４．４．１６　ｂｙ　Ａｒｔａｎｅ．

6. 参考にするといい本

7. クイックリファレンス

8. この文書について

追記：

by Artane.(NCA02423@niftyserve.or.jp 又は FNA0011@FNA)

[1]	これを、「 2 パスコンパイル」と言い、gcc や LSI-C 等はこの方法を取っていますが、場合によってはソースコードから直接オブジェクトに変換する方法 ( 1 パスコンパイル) もあります。
[2]	仮想のコードに変換されたりしたものや、そのままの文字列を解釈する方法。速度は遅くなるが、互換性は高く出来る。
[3]	ライブラリとは、簡単に言えば細かいプログラムを予めマシンコード (実行可能なコード) の形で寄せ集めて置いた物。これを入れ換える事によって、バージョンアップや (ある程度の) 対象システムの変更が元プログラムの変更や再コンパイルなくして可能となる。
[4]	勿論、例外もある。ハードに依存する部分や MPU が同じならば… と言う前提で高速化を狙って部分的にアセンブラで書く事も少なくないし、基本ソフト等は直接実行可能なバイナリイメージで配付される。そして、最近は同じ MPU と似た OS ならばどの機械でも使える形式でのマシンコードによる配付も行われつつある ( …DIY の精神からは外れますが) (例えば、80x86 系 MPU を積む UN*X 機での標準フォーマットとする為に出来た elf binary フォーマット等も動く様であるが、果たしてどの程度流れているか不明)。又、商業ベースで配付される物は、バイナリで配付される上にコピープロテクトコピーを防ぐ為にパスワードや鍵がなければインストール出来ない様に暗号化したりなどする) がかかっている場合も少なくありません。以下、「配付」とは、「フリーソフトの配付」と言う限定的な意味で使います。
[5]	コンパイラを今使っている環境で使える様にするために、HD に転写したり、環境構築したりする、と言う意味で使った。厳密な定義とは違う。
[6]	「バケツリレー」の概念は、大規模ネットワークの普及と共に過去の物へとなりつつある…らしいです。しかし、ネットワークの回線時間(資源とも言う)を喰うのは相変わらずだし、大規模なホストやネットワークの先からは、相変わらず幾つかのホストを経由する場合が多いので、時間を使うのは余りいい事ではないのです。ネットワークを通じてのニュース ( BBS に於ける掲示板相当と思えば良い) を使った流通の場合、特に配慮が必要です。
[7]	gcc は圧縮した状態で全体のソースコードで 9 M、一回ヴァージョンアップするのに差分が 900K 前後 (圧縮して) なので、仲々 Linux 対応版のバイナリが公表されない様です。バイナリで圧縮でも 1.5 M 以上は行ってしまいますからね。
[8]	安全上の問題があるので、古いバージョンの lib ( lib.so.2. 等のメジャーバージョンが新しく入れる物と明らかに違う物) を残し、cp を使って転写してください。
[9]	これも試行錯誤の上で出た結論。何故 HP 系なのかは(謎)だとしか言い様がない。尚、X ウインドウ専用版 fu の Xfree86 / TOWNS での動作は、頻繁に落ちるためやめた方がいいです。
[10]	OS が違うので「保険」をかけていると思って下さい。
[11]	出来れば cp を使って下さい。ln -s はもしも fu の場所が変わるとスカに終わるので。make install する手もありますが、私は余り趣味ではないので使わない。
[12]	ダウンロードの際は、適当な名前に変更して行う事になります…
[13]	ここでは、シェルがbashである。と言う前提でやっていますので、他のシェルをお使いの場合にはループの組みかたを変えるか、patch1～patch5を順に手動で当てる必要があります。