次のページ
前のページ
目次へ
「とりあえずmakeしよう」(1) 第三版 Rel:apr.16.1994
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
注意：
この文はあくまでも「私的趣味の為のLinux 」が目的であって、本来の「まっとう
な」システムの使用法やファイル配置とは異なる可能性が大きいです。
従って、「システムマネージャー」を狙ってLinux で勉強されてる方は読まない方
が身の為です。（まじ）
以前の版を出してからＬｉｎｕｘの使用環境も変わって来ました故、全面改訂致し
ます。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
（０）なぜ、コンパイルが必要か
コンパイルとは、ある規則に従って書かれた文書（ソース）を実行できるコード
（オブジェクト）に変換する事を（乱暴な言い方ですが）指します。（アセンブルと
違うのはアセンブルは機械に密着していて、文から直接オブジェクトに変換する作業
なのに対して、コンパイルはソースコードからアセンブルの為のコードを出す(*1)
作業なのです）
(*1) これを、「２パスコンパイル」と言い、gcc やLSI-C 等はこの方法を取って
いますが、場合によってはソースコードから直接オブジェクトに変換する方法
（１パスコンパイル）もあります。
ここで、オブジェクトは機械毎に違うし、基盤となるＯＳによっても異なります。
仮にパソコンの世界ならばPC98,FM-Towns,IBM-PC,Mac,X68000,AMIGA…といま挙げた
だけでもハードの分類だけで沢山ありますし、ＯＳによってもMS-DOS,OS-9,System7,
386BSD,Linux…ハードウェアの違いはある程度は中にあるＭＰＵとＯＳが同じならば
ある程度吸収してくれるとはいえ、そうだとしても沢山の分類があります。
ここで仮にアセンブラしかなかったならば、それぞれのＯＳ、それぞれのＭＰＵで
全く違う書き方をしなければならない上に複雑な計算をやらせるとしたら…考えただ
けで脳ミソが爆発してしまいます。
こういった「ハード間の差異」や「記述の複雑さ」を乗り越えるためにインタプリタ
(*2)やコンパイラが色々な仕様（BASIC,PASCAL,FORTRAN,そしてC 等）で作られ、その
外側の、ＯＳ寄りな部分での差異をライブラリ(*3)が埋めているのです。
(*2) 仮想のコードに変換されたりしたものや、そのままの文字列を解釈する方法。
速度は遅くなるが、互換性は高く出来る。
(*3) ライブラリとは、簡単に言えば細かいプログラムを予めマシンコード(実行可能
なコード)の形で寄せ集めて置いた物。これを入れ換える事によって、ヴァージョン
アップや(ある程度の)対象システムの変更が元プログラムの変更や再コンパイルな
くして可能となる。
ここで、UN*Xの世界に目を向けて見ましょう。
大型のスーパーコンピュータからＷＳ、そして今貴方が使っているTowns や IBM-PC
と言ったパソコンまで雑多なハード仕様とＭＰＵに細かく違うＯＳ仕様が混在していま
す。
これらの間で、同じかそれに近い書き方でプログラムを書くことが出来れば、ある
機械で書き、動かしたプログラムの成果の殆どを全く違う機械で実現する事が出来ます
又、その事によって、ユーザとして使ってる人達がプログラムを書く労力を激減する
事が出来るのです。
従って、UN*Xでは、MS-DOS等と違い、通常はC 等の高級言語によって書かれたソース
コードの形で（フリーな）プログラムが流通しています。(*4)
(*4) 勿論、例外もある。ハードに依存する部分やＭＰＵが同じならば…と言う前提で
高速化を狙って部分的にアセンブラで書く事も少なくないし、基本ソフト等は直接
実行可能なバイナリイメージで配付される。
そして、最近は同じＭＰＵと似たＯＳならばどの機械でも使える形式でのマシン
コードによる配付も行われつつある(…DIY の精神からは外れますが)
（例えば、80x86 系MPU を積むUN*X機での標準フォーマットとする為に出来たelf
binaryフォーマット等も動く様であるが、果たしてどの程度流れているか不明）
又、商業ベースで配付される物は、バイナリで配付される上にコピープロテクト
（コピーを防ぐ為にパスワードや鍵がなければインストール出来ない様に暗号化した
りなどする）がかかっている場合も少なくありません。
以下、「配付」とは、「フリーソフトの配付」と言う限定的な意味で使います。
（１）コンパイラとｍａｋｅ
ソースコードで入手した物をコンパイルするには、それに適合しているコンパイラが
必要になります。 今貴方が使っているTowns やIBM-PCにおけるLinux では、gcc が標
準のＣ言語コンパイラとなっていますので、まずはそれをインストール(*5)して下さい
(*5) コンパイラを今使っている環境で使える様にするために、ＨＤに転写したり、
環境構築したりする。と言う意味で使った。厳密な定義とは違う。
さて、これでＣの知識のある人ならば、"HELLO WORLD"なんぞと表示させてニヤリと
する所ですが、通常流通しているプログラムは個別にコンパイルしていたのではとても
手間がかかってしまうし、作る側も虫取り（デバッグ：ミスを修正する）の手間が
かかってしまうので、コンパイルを支援するツールが幾つも作られました。
その中でもポピュラーかつ強力なのがｍａｋｅ（Linux ではGNU-make）です。
これは、詳しくはＣ言語の本を見て欲しいのですが（奥が深いので解説はしない）、
ソースファイルとオブジェクトファイルを対応させておいて、オブジェクトが出来た後
にソースが書き直されていたりしたならばコンパイルをやり直したり、特定の作業を行
う様にする対応表（バッチでもある）をMakefile等と名付けられたファイルに書いてお
く事によって半自動でコンパイルを進ませてくれるツールです。
例えば、
----------------------------------以下、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
------------------------------------Makefile例終了----------------------------
等とこれはイイカゲンな物（架空の物）なのですが、こういった感じで書きます。
この時、単にmakeとすればソースからtestと言うオブジェクトが作られるし、
make cleanとすれば、オブジェクトを消してくれます。
その他、Bison(Yacc) やらLintやらlex (Flex)やら色々とありますが、それは後学の
タネにしましょう。(とりあえず、C の使い方だけでも身に付けないときつい物がある)
[チェックポイント]
・makeの基本的な文法
・c のマクロの書き方
・機種やＯＳに依存している記述への対応、特にＢＳＤ系かＳＹＳＶ系かでの判断
・コンパイラへのオプションの書き方
（２）配付形態
（０）で私は「UN*Xの世界では通常ソース配付である。」と書きました。しかし、
バラバラでは色々都合が悪いし、大きさもそのままでは電話代や課金がかさんで問題
が出てきます。（その上、UN*Xの世界ではバケツリレー的に通信してるので、他の端末
に迷惑をかけると言う問題が生じる事も少なくない(*6)）
(*6) 「バケツリレー」の概念は、大規模ネットワークの普及と共に過去の物へとなり
つつある…らしいです。しかし、ネットワークの回線時間(資源とも言う)を喰うの
は相変わらずだし、大規模なホストやネットワークの先からは、相変わらず幾つか
のホストを経由する場合が多いので、時間を使うのは余りいい事ではないのです。
ネットワークを通じてのニュース（ＢＢＳに於ける掲示板相当と思えば良い）
を使った流通の場合、特に配慮が必要です。
そこで登場するのがアーカイバや圧縮ツールと言う物です。
大まかに配付に於いて使われる形態は、
(a) tar を使ってまとめる(圧縮せず)
(b) tar でまとめた物をcompress(gzip)で圧縮する
(c) tar でまとめた物をLHa(LHarc)等の圧縮機能付きアーカイバで圧縮する
(d) LHa/UN*X等の、UN*X対応の圧縮機能付きアーカイバで圧縮する
(e) zip を使って、LHaと同じ方法で圧縮する
(f) sharを使って、ソースコードをそのまま一個にまとめる。この場合、圧縮
やバイナリ化された物は送れない。
に大別されますが、(d) は普及の関係か、余り一般的ではありません。
又、アーカイブされた物を流すには、
(1) テキストならば、そのまま流す
(2) バイナリイメージを流す。これはftpサイトやBBS等で用いられる普通の方式
(3) ish を使ってバイナリをテキスト化する (バイナリ化にはishを用いる)
(4) uuencodeを使ってテキスト化する (バイナリ化にはuudecodeを用いる)
(3) と(4) は、ＢＢＳやニュースグループでの書き込みで主に用いられます。
[チェックポイント]
・拡張子での配付形態の違い(（７）参照)
（３）ライブラリ等の配置
少し、インストールに言及しましょう。
まず、当然ながらインストーラなり手動なりで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のパッケージの中に入っていますので、そちらを持っている
方はそちらがお得です:）
(*7) gcc は圧縮した状態で全体のソースコードで９Ｍ、一回ヴァージョンアップする
のに差分が９００Ｋ前後（圧縮して）なので、仲々Linux 対応版のバイナリが公表
されない様です。バイナリで圧縮でも１．５Ｍ以上は行ってしまいますからね。
これ以外にも、各種のライブラリィ(プログラム実行時もしくは作成時にリンクされ
る、最もOS寄りの部分)を入手して/libや/usr/libに配置する必要があります。
1994/4/16 現在のLinux 向けのc ライブラリィのリビジョンは4.5.19ですので、
以下に示す三つをダウンロード（１．５Ｍはあります ^^;）するか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
最低限、以上の操作が必要です。
(*8) 安全上の問題があるので、古いヴァージョンのlib （lib*.so.2.*等のメジャー
ヴァージョンが新しく入れる物と明らかに違う物）を残し、cpを使って転写して
ください。
これ以外に現在使っているヴァージョンの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 でのライブラリの配置構造
（４）ｍａｋｅする
＊＊コラム＊＊
今配付されているソフトの幾つかはconfigureなるシェルスクリプトを動かして半自動
でMakefileやOS依存情報を作成してくれる物があります（最近配付されてるgnu 系のソ
フトは殆どがそうです）。 しかし、コンパイラやＯＳの細かい仕様の関係で必ずしも
正確な物を作ってくれない場合が少なからずあります。
そこで、単にconfigure →make するだけでなく、問題箇所を最適な形で修正する術
を覚える必要があります。
＊＊コラム終わり＊＊
（ａ） 変更の必要が最低限なもの
では、ここでは殆ど変更無で動く物を取り上げましょう。
例として、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)
(*9) これも試行錯誤の上で出た結論。何故HP系なのかは(謎)だとしか言い様がない
尚、X ウインドウズ専用版fuのXfree86/TOWNSでの動作は、頻繁に落ちるため
やめた方がいいです。
machine.h をエディタで以下のように書き換えます。
以下、＞の後に来る行を、次の様に書き換えます。
＞#define H2050 1
#define H2050 0
＞#define HP9000 0
#define HP9000 1
次にMakefileをHP9000用の物に置き換えて、更に書き換えます。
まず、
cp MakeHP9000 Makefile
貴方が好みのエディタを起動して、（念の為に）Makefileを書き換えます。(*10)
(*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
と打ち込んで後はエラーが出ないことを祈りつつ待ちましょう。（ここからがイバラ
の道なのですが…）
警告が出るかもしれませんが、それは無視してとりあえず出来ました。
さて、試しに使って見ましょう。
./fu
使い勝手がいまいちだ。と思ったら、.setup.fuを使いやすい様に書き換えて再び
ホームディレクトリィに複写（マニュアル参照）します。
納得出来たら、ln -sf /usr/src/fu302/fu /usr/local/bin か
cp ./fu /usr/local/bin としてすぐに実行出来るようにしましょう。(*11)
(*11) 出来ればcpを使って下さい。ln -s はもしもfuの場所が変わるとスカに終わるの
で。make install する手もありますが、私は余り趣味ではないので使わない。
#尚、この版のリリースと前後して、源著作者からＯＫを頂いた上でgzipやzip を使える
#様に改良したfuの差分を公表する予定です（現在、更成る改良中）。期待しないでお
#待ち下さい:-)
（ｂ）Ｌａｓｅｒ ５のＣＤから引っ張ってくる
さて、この項では以前はＧＮＵ−ＣＤ２から引っ張って来ていましたが、今は
iso9660 フォーマットのＣＤ−ＲＯＭでのファイル名の制限を克服するための
RockRidge 形式（別に名前の対応表を持って置いて、そちらの名前を参照する）
が普及しているお蔭でsed 等を使ってスクリプトを書いたりなどする必要はなくな
りつつあります。
一応、この項の最後に参考までに残して置きますので、古いＣＤ−ＲＯＭから、
ＭＳ−ＤＯＳのテキストとして記述したソースコードを引っ張ってくる際に参考に
して下さい。
今回は、minicom 等の端末から使うzmodemを取り上げます。Linux から各種BBS
(win.or.jp 等の、端末を一般に開放してるU*IXホストも含む）にアクセスしてダウン
ロードやアップロードする際には必須のソフトです。
まず、ＣＤ−ＲＯＭをMount します。（/etc/fstabへの登録を忘れずに:）
ＣＤ−ＲＯＭは/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やREADME等を読めば分かると
思いますし、rz/sz は無変更でmakeしても動くので、宿題にします:-)
＊＊コラム：古い（もしくはＭＳ−ＤＯＳ専用の）ＣＤ−ＲＯＭから転送する＊＊
ＧＮＵ−ＣＤ２においては、MS-DOSで読む。と言う制約から、ファイル名が８文字
＋拡張子３文字以内に設定されています。
又、ファイルの属性（ファイルがどういう物か示す…chmod で変えられる）も全く
違いますし、もしもテキストがＭＳ−ＤＯＳ仕様ならば、mstrip 等で余計な改行
コードを消す必要があります。
そこで、記録されてるファイルネームと本来の物との対応表を用意しておいて、
UN*X上で復元する。と言う事を行うコマンドが、cdrname （Towns 版Linux に添付。
又、ＧＮＵ−ＣＤ２等にソースコードが収録されている）です。
例えばｉｓｈでは、ＧＮＵ−ＣＤ２から /usr/src/ish にファイルを転送して、
mstrip *
cd /usr/src/ish
cdrname
とすれば、ファイル名を復元してくれる筈です。しかし、ＣＤ−ＲＯＭから落とし
た場合には、最後に余計な. が付いて来る事があります。これはしょうがないので、
SED(Stream EDitor)等を使って名前を変更した後でcdrname する必要があります。
----------------------以下、スクリプト。---------------------------------------
#!/bin/sh
ls *. | sed -n 's/\(.\)\.$/\mv & \1/p' | sh -
-------------------------------------------------------------------------------
さて、これでファイル名（パス）が修復されました。
次に、MakefileをLinux 向けに変更します。（変更なしでも出来そうだが、保険をか
けておく）
ＯＳ依存情報を（ａ）と同じように変えれば良いので、宿題にします。(^^)
(但し、-ltermcap や -lcurses は必要ない。)
さて、後はmake一発で実行形式が出来る筈です。
＊＊コラム終わり＊＊
（ｃ）カーネルを構築する（パッチの使い方）
ここでは、ダウンロードした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 対応
β１版パッチを当ててみます。カーネルソース自体をpl5 までアップグレードしないと
β１版パッチは当たらないので、注意しましょう。
まず、おおもとのLinux のカーネル（中心部）の元のコードを展開します。(*12)
(/---/は、圧縮状態の元ファイルがあるディレクトリィ)
cd /usr/src
zcat /---/linux100.tgz | tar xvoof -
(*12) ダウンロードの際は、適当な名前に変更して行う事になります…
次に、予めダウンロードして/usr/srcに展開しておいたpatch1からpatch5迄を当て
ます。流通してる場所によって配布形態が違うので、ここでは展開について詳述しま
せん。
for i in patch#[1-5] ; do patch -p <$i ; done
(*13)
(*13) ここでは、シェルがbashである。と言う前提でやっていますので、他のシェル
をお使いの場合にはループの組みかたを変えるか、patch1〜patch5を順に手動で
当てる必要があります。
次に、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 での機種・ＯＳ依存部分の解析とそれを指定するのに必要とされる情報の記述
・patch -p の使い方
・diff の使い方
（５）あとがき
最初は「苦戦日記」調の物を予定していたのですが、全くアホな事に、中途半端な
チュートリアルもどきになってしまいました…
この文は収録されるかもしれないLinux-CDではなくて、Nifty からダウンロードされ
る人達を対象にしてしまってるので、（４）の多くは無意味な情報になってしまった様
な感じで更に情け無い…
今回はＸに関連した事項やライブラリィの作成等については省きました。
続きを出せれば、そこで触れる事になるでしょう。
ここで出しても良かったのかもしれませんが、私自身の知識を越えてるので…
何方か、libcやXlibに関する具体的仕様を記述した書物（出来れば日本語で安い物）
等についてお教え願います…
ともあれ、これが「到達目標」なのではなく、全く別の「目標」を目指す為の道標と
なり、又、同じ様に苦戦されてる人達の灯となることを祈っております…
１９９４．４．１６ ｂｙ Ａｒｔａｎｅ．
（６）参考にするといい本。
・「入門Ｃ言語」「実用Ｃ言語」「応用Ｃ言語」：アスキー刊
（アスキーラーニングシステムシリーズ）
貴方の理解レベルにあわせてどれを買うか決めて下さい。
初歩から８９３までわかりやすい本だと思います。
・「ＵＮＩＸスーパーテキスト（上）（下）」：技術評論社刊
はっきりいってこれはオススメです。（上）が３４００円
（下）が３７００円と一寸高いですが、UN*Xに関して体系的
かつ実情に沿った形で編集されており、大金を払う価値が
ある。と断言してしまいます。下手なUN*X本買うよりも安
いです。
・「はじめての”Ｃ”」：技術評論社刊
Ｃ言語の概念を学ぶにはいい本です。まぁ、現在は乱発気味
な状況にＣの本はあるので、好きなのを選ぶのがいいでしょう
他に、ＡＮＳＩから出てる仕様書等も必要があれば持って置いて損はないでしょう。
（と言うか、貧乏なので私は買ってないが、本格的にハマる場合は必ず必要になる。）
（７）クイックリファレンス
(a) 解凍
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
(b) make （大体において共通事項）
make : 全てのファイルの存在関係を読んで作業（主にコンパイル）を行う
make install : makeで出来上がった実行形式ファイルを実行出来る環境に移したり
環境構築したりする。
make clean : 一からコンパイルしなおすべく、オブジェクトや実行形式等を消す。
make depend 又は
make .depend : ソースコードと他のソースコードの対応関係(地図)を付け加える。
(c) gcc のコンパイラオプション（主な物だけ…詳細は
「インサイド GNU Cコンパイラ」（実教）や
gcc 添付のinfo 等を見て下さい。）
-D定義名 : 定義名をソースコードで#define したのと同じくする。
-D定義名=値 : 定義名を値として#defineしたのと同じくする。
-Lライブラリィ位置 : ライブラリィのある場所を指定する。
-lライブラリィ名 : ライブラリィをリンク対象に加える。
-static : 単体で実行可能なファイルを作る（リンクする）
-s : シンボル（ラベル）情報を実行形式オブジェクトに入れない。
-g : シンボル情報を詳細まで残す。デバッガを使ってバグ取りをする時に必要。
-Iヘッダ位置 : ヘッダのあるディレクトリィ(普通、/usr/include)を指定する。
-O (-O2 及び -O6 が代表的) : コンパイルで最適化（オプティマイズ）を行う。
これによってオブジェクトの大きさや実行速度を向上させられる。
-S : コンパイルのみ行ってアセンブラ(gas) のソースを吐かせる。
-c : コンパイル（アセンブル）のみ行ってオブジェクトを吐かせる。
-o 実行形式名 : 実行形式ファイルを指定された名前で出力する。（リンカ）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
追記：ご多分にもれず、この文書はコピーフリーです。が、オリジナルが私の書いたこ
れであること（著作者人格権）とそれに付帯する権利だけは放棄しません。
（但し、これは主張のみであり、これをウリにして余程の不労所得を上げてる場合以
外は金などを請求したり、咎めたりする意思はありません。無断転載歓迎。）
by Artane.(NCA02423@niftyserve.or.jp 又は FNA0011@FNA)
次のページ
前のページ
目次へ