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

artane

NCA02423@niftyserve.or.jp

1994年4月16日

注意:この文はあくまでも「私的趣味の為の Linux 」が目的であって、本来の 「まっとうな」システムの使用法やファイル配置とは異なる可能性が大きいです。 従って、「システムマネージャー」を狙って Linux で勉強されてる方は読まない方 が身の為です。(まじ)

以前の版を出してから Linux の使用環境も変わって来ました故、全面改訂致します。

Note: この文書は、1994年4月16日以来、更新されていません。 現在とは事情が異なる部分があるので、ご注意ください。(JF Project)


Table of Contents
0. なぜ、コンパイルが必要か
1. コンパイラと make
2. 配付形態
3. ライブラリ等の配置
4. make する
4.1. 変更の必要が最低限なもの
4.2. Laser 5 の CD から引っ張ってくる
4.3. カーネルを構築する (パッチの使い方)
5. あとがき
6. 参考にするといい本
7. クイックリファレンス
7.1. 解凍
7.2. make (大体において共通事項)
7.3. gcc のコンパイラオプション
8. この文書について

0. なぜ、コンパイルが必要か

コンパイルとは、ある規則に従って書かれた文書 (ソース) を実行できるコード (オブジェクト) に変換する事を (乱暴な言い方ですが) 指します。(アセンブルと 違うのはアセンブルは機械に密着していて、文から直接オブジェクトに変換する作業 なのに対して、コンパイルはソースコードからアセンブルの為のコードを出す [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] 。)

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

  1. tar を使ってまとめる(圧縮せず)

  2. tar でまとめた物を compress (gzip) で圧縮する

  3. tar でまとめた物を LHa (LHarc) 等の圧縮機能付きアーカイバで圧縮する

  4. LHa / UN*X 等の、UN*X 対応の圧縮機能付きアーカイバで圧縮する

  5. zip を使って、LHa と同じ方法で圧縮する

  6. shar を使って、ソースコードをそのまま一個にまとめる。この場合、圧縮 やバイナリ化された物は送れない。

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

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

  1. テキストならば、そのまま流す

  2. バイナリイメージを流す。これは ftp サイトや BBS 等で用いられる普通の方式

  3. ish を使ってバイナリをテキスト化する (バイナリ化には ish を用いる)

  4. uuencode を使ってテキスト化する (バイナリ化には uudecode を用いる)

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

チェックポイント:

  • 拡張子での配付形態の違い((7)参照)


3. ライブラリ等の配置

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

gcc-2.5.8 が 1994/4/16 現在の Linux / Towns 標準の筈 [7] ですので、展開された gcc は以下の様な配置になってると思います。 (ここでは、FFMHOB での配付形態の物を zcattar を使って
    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 の細かい仕様の関係で必ずしも 正確な物を作ってくれない場合が少なからずあります。そこで、単に configuremake するだけでなく、問題箇所を 最適な形で修正する術を覚える必要があります。

**コラム終わり**


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/bincp ./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
 でOKです。

 そして、ドキュメントに従って新しく出来たデバイスを/devにmknodで登録します。 その後、sync→rebootで一旦MS−DOSに戻ります。
  sync
  reboot -h now
さて、MS−DOS から新しい 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 に関する具体的仕様を記述した書物 (出来れば日本語で安い 物) 等についてお教え願います…

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

  1994.4.16 by Artane.


6. 参考にするといい本

・「入門 C 言語」「実用 C 言語」「応用 C 言語」:アスキー刊
           (アスキーラーニングシステムシリーズ)
           貴方の理解レベルにあわせてどれを買うか決めて下さい。
           初歩から 893 までわかりやすい本だと思います。

・「UNIX スーパーテキスト (上) (下)」:技術評論社刊
           はっきりいってこれはオススメです。(上) が 3400 円、
           (下) が 3700 円と一寸高いですが、UN*X に関して体系的
           かつ実情に沿った形で編集されており、大金を払う価値が
           ある。と断言してしまいます。下手な UN*X 本買うよりも
           安いです。

・「はじめての "C" 」:技術評論社刊
           C 言語の概念を学ぶにはいい本です。まぁ、現在は乱発気味な
           状況に C の本はあるので、好きなのを選ぶのがいいでしょう。

 他に、ANSI から出てる仕様書等も必要があれば持って置いて損はないでしょう。
(と言うか、貧乏なので私は買ってないが、本格的にハマる場合は必ず必要になる。)


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

7.1. 解凍

tar+compress:

拡張子=.tar.Z 又は .taz (.tazの場合はLinux 上で mv *.taz *.tar.Z 等として名前の変更が必要。 但し gzip から派生した zcat ではこの作業は要らなくなりました。)
  zcat SOURCE.tar.Z |tar xvf - -C (頭のディレクトリィ)

tar+gzip:

拡張子=.tar.gz 又は .tpz 又は .tgz
  zcat パスネーム |tar xvoof - -C (頭のディレクトリィ)

LHa+tar:

拡張子=.lzh
  lha x SOURCE.lzh
  tar -xvoof SOURCE.tar -C (頭のディレクトリィ)

LHa/UN*X:

拡張子=.lzh
  cd (頭のディレクトリィ)
  lha x SOURCE.lzh

zip/unzip:

拡張子=.zip
  cd (頭のディレクトリィ)
  unzip x SOURCE.zip


7.2. make (大体において共通事項)

make :

全てのファイルの存在関係を読んで作業(主にコンパイル)を行う

make install :

makeで出来上がった実行形式ファイルを実行出来る環境に移したり 環境構築したりする。

make clean :

一からコンパイルしなおすべく、オブジェクトや実行形式等を消す。

make depend 又は make .depend :

ソースコードと他のソースコードの対応関係(地図)を付け加える。


7.3. gcc のコンパイラオプション

(主な物だけ…詳細は「インサイド GNU Cコンパイラ」(実教)や gcc 添付の info 等を見て下さい。)

-D定義名 :

定義名をソースコードで#define したのと同じくする。

-D定義名=値 :

定義名を値として#defineしたのと同じくする。

-Lライブラリィ位置 :

ライブラリィのある場所を指定する。

-lライブラリィ名 :

ライブラリィをリンク対象に加える。

-static :

単体で実行可能なファイルを作る(リンクする)

-s :

シンボル(ラベル)情報を実行形式オブジェクトに入れない。

-g :

シンボル情報を詳細まで残す。デバッガを使ってバグ取りをする時に必要。

-Iヘッダ位置 :

ヘッダのあるディレクトリィ(普通、/usr/include)を指定する。

-O (-O2 及び -O6 が代表的) :

コンパイルで最適化(オプティマイズ)を行う。 これによってオブジェクトの大きさや実行速度を向上させられる。

-S :

コンパイルのみ行ってアセンブラ(gas) のソースを吐かせる。

-c :

コンパイル(アセンブル)のみ行ってオブジェクトを吐かせる。

-o 実行形式名 :

実行形式ファイルを指定された名前で出力する。(リンカ)


8. この文書について

追記:

ご多分にもれず、この文書はコピーフリーです。が、オリジナルが私の書いたこ れであること(著作者人格権)とそれに付帯する権利だけは放棄しません。 (但し、これは主張のみであり、これをウリにして余程の不労所得を上げてる場合以 外は金などを請求したり、咎めたりする意思はありません。無断転載歓迎。)

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

Notes

[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を順に手動で 当てる必要があります。