1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
.\"
.\" Copyright (c) 1994 University of Maryland
.\" All Rights Reserved.
.\"
.\" Permission to use, copy, modify, distribute, and sell this software and its
.\" documentation for any purpose is hereby granted without fee, provided that
.\" the above copyright notice appear in all copies and that both that
.\" copyright notice and this permission notice appear in supporting
.\" documentation, and that the name of U.M. not be used in advertising or
.\" publicity pertaining to distribution of the software without specific,
.\" written prior permission. U.M. makes no representations about the
.\" suitability of this software for any purpose. It is provided "as is"
.\" without express or implied warranty.
.\"
.\" U.M. DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL U.M.
.\" BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
.\" IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.\" Author: James da Silva, Systems Design and Analysis Group
.\" Computer Science Department
.\" University of Maryland at College Park
.\"
.Dd September 29, 1997
.\" jpman %Id: crunchgen.1,v 1.3 1997/07/29 13:43:59 konuma Stab %
.Dt CRUNCHGEN 1
.Os BSD 4
.Sh 名称
.Nm \&crunchgen
.Nd クランチバイナリ構築環境を作成する
.Sh 書式
.Nm \&crunchgen
.Op Fl fql
.Op Fl m Ar makefile-name
.Op Fl c Ar c-file-name
.Op Fl e Ar exec-file-name
.Op Ar conf-file
.Sh 解説
クランチバイナリ(crunched binary)は、
たくさんの別々のプログラムをひとつにまとめて
単一の実行形式にしたプログラムです。
クランチバイナリの main() 関数は、argv[0] の値をみて、
どのコンポーネントプログラムが実行されるべきかを決定します。
複数プログラムをクランチしてひとつにまとめる主たる理由は、
インストールフロッピあるいはシステム回復フロッピ上に、
できるだけ多くのプログラムを収納するためです。
.Pp
.Nm crunchgen
は
.Ar conf-file
に記述されたクランチバイナリのための設定項目を読み込み、
Makefile とそれに付随するトップレベルの C ソースファイルを生成します。
これらはビルド時に各コンポーネントプログラムからクランチした実行形式を
作成します。
オプションにより、
.Nm
は、各コンポーネントプログラムに対して、
そのソースディレクトリの Makefile から
プログラムを構成するオブジェクトファイル(.o)を決定することも試みます。
この情報は実行のたびにキャッシュされます。
.Nm
は関連するもうひとつのプログラム
.Nm crunchide
を用い、全ての不要なシンボルを隠すことで
コンポーネントプログラム間のリンク時のシンボル競合を防ぎます。
.Pp
.Nm
実行後、 ``make -f <conf-name>.mk'' を実行することで
クランチバイナリを作成できます。
コンポーネントプログラムのオブジェクトファイルは既に作成されている
必要があります。
出力される makefile に含まれる ``objs'' ターゲットは、
各コンポーネントプログラムのソースディレクトリで make を実行し、
ユーザのためにオブジェクトファイルを作成してくれます。
しかしこのターゲットは自動的には実行されません。
リリースエンジニアリング環境では、オブジェクトを他のディレクトリで
修正するのは一般に望ましくないからです。
.Pp
オプションは以下の通りです:
.Bl -tag -width indent
.It Fl c Ar c-file-name
出力する C のファイル名を
.Ar c-file-name
とします。デフォルトの名前は ``<conf-name>.c'' です。
.It Fl e Ar exec-file-name
クランチバイナリの実行形式ファイルの名前を
.Ar exec-file-name
とします。デフォルトの名前は ``<conf-name>'' です。
.It Fl f
キャッシュを消去し、キャッシュされていたパラメータを強制的に再計算します。
.It Fl l
名前の表示。このバイナリが対応する名前を一覧表示します。
.It Fl m Ar makefile-name
出力する Makefile の名前を
.Ar makefile-name
とします。デフォルトの名前は ``<conf-name>.mk'' です。
.It Fl q
静粛処理モード。状況報告メッセージを抑制します。
.El
.Sh CRUNCHGEN コンフィギュレーションファイルコマンド
.Nm
は、クランチバイナリのコンポーネントについて記述した設定項目を
.Ar conf-file
から読み取ります。
最も単純な場合は、各コンポーネントプログラム名を、
そのソースファイルが置かれたトップレベルのディレクトリ名とともに、
単に列挙するだけです。
次に
.Nm
は(ソースの makefile によって)オブジェクトファイルリストと
その位置を求め、それをキャッシュします。
もっと特殊な場合には、
.Nm
が必要とするあらゆるパラメータを、ユーザが手動で指定することができます。
.Pp
.Ar conf-file
のコマンドは以下の通りです:
.Bl -tag -width indent
.It Nm srcdirs Ar dirname ...
コンポーネントプログラムのソースディレクトリがあるソースツリーのリスト。
これらのディレクトリは BSD の ``<source-dir>/<progname>/'' 方式を
用いて検索されます。
.Nm srcdirs
行は複数あってもよく、ディレクトリは記述された順に検索されます。
.It Nm progs Ar progname ...
クランチバイナリを構成するプログラムのリスト。
.Nm progs
行は複数あっても構いません。
.It Nm libs Ar libspec ...
クランチバイナリのリンク時に含めるライブラリ指定のリスト。
.Nm libs
行は複数あっても構いません。
.It Nm ln Ar progname linkname
argv[0] に
.Ar linkname
が現われたときはいつも
.Ar progname
を起動するよう、クランチバイナリに要請します。
これにより、起動時の名前によって振る舞いを変えるようなプログラムも
正しく動作するようにできます。
.El
特別な状況、例えば
ソースファイルがないとか、
従来の Makefile によらないビルドを行うといった
場合に対応するため、以下に述べる
.Nm special
コマンドを用いてコンポーネントプログラムの
.Nm
パラメータを指定できます。
.Bl -tag -width indent
.It Nm special Ar progname Nm srcdir Ar pathname
プログラム
.Ar progname
のソースディレクトリを指定します。
通常は指定されたディレクトリ
.Nm srcdirs
内の
.Ar progname
ディレクトリを検索して決定されます。
.It Nm special Ar progname Nm objdir Ar pathname
プログラム
.Ar progname
のオブジェクトディレクトリを指定します。
通常はディレクトリ
.Ar srcdir
内の
.Dq Pa obj
という名前のディレクトリを探し、もし見つからなければ、ディレクトリ
.Ar srcdir
自身が
.Ar objdir
となります。
.It Nm special Ar progname Nm objs Ar object-file-name ...
プログラム
.Ar progname
のオブジェクトファイルのリストを指定します。
通常は、
.Dq Nm srcdir / Pa Makefile
をインクルードし $(OBJS) の値を出力するような一時 makefile を構築する
ことで決定されます。
.It Nm special Ar progname Nm objpaths Ar full-pathname-to-object-file ...
プログラム
.Ar progname
のオブジェクトファイルのパス名を指定します。
通常は
.Nm objs
リスト中の各ファイルのパス名の先頭に
.Nm objdir
を付加することで決定されます。
.It Nm special Ar progname Nm keep Ar symbol-name ...
プログラム
.Ar progname
の保持リストに、指定するシンボルのリストを追加します。
各シンボルの前にはアンダスコアが付加され、
.Xr crunchide 1
フェーズでは
.Fl k
オプションの引数となります
このオプションはシンボルが衝突するときの最後の拠所ですが、
シンボル解決の唯一の方法である場合もあります。
.El
.Pp
実際に
.Nm
が必要とするのは
.Nm objpaths
だけですが、
これは
.Nm objdir
と
.Nm objs
から求められ、これらも
.Nm srcdir
から求められます。
ですから、もし可能なら、初期のパラメータを指定し、あとは
.Nm
に求めさせたほうが便利な場合もあります。
.Pp
.Nm
が生成する makefile はオプションのターゲット
.Ar objs
を含みます。
これは、各コンポーネントプログラムのソースディレクトリ内で make を実行して
オブジェクトファイルを作成するターゲットです。
これがうまく動作するためには
.Nm srcdir
および
.Nm objs
パラメータが正しいものでなくてはなりません。
もしこれらの値があるプログラムに対して不正なものであると、
.Ar objs
ターゲットではそのプログラムはスキップされてしまいます。
.Sh 実行例
.Nm
の入力コンフィギュレーションファイルの例として
.Dq Pa kcopy.conf
の内容を示します。
.Pp
.nf
srcdirs /usr/src/bin /usr/src/sbin
progs test cp echo sh fsck halt init mount umount myinstall
ln test [ # test は [ として起動することもできる
ln sh -sh # init は argv[0] を "-sh" としてシェルを起動する
special myprog objpaths /homes/leroy/src/myinstall.o # ソースなし
libs -lutil -lcrypt
.fi
.Pp
このコンフィギュレーションファイルでは、
いくつかの基本的なシステムユーティリティと
自家製のインストールプログラム ``myinstall'' から成る
小さなクランチバイナリを記述しています。
ソースディレクトリは全く指定されていませんが、
オブジェクトファイルは
.Nm special
行で直接指定されています。
.Pp
クランチバイナリ ``kcopy'' は以下のようにして作成できます:
.Pp
.nf
% crunchgen -m Makefile kcopy.conf # Makefile と kcopy.c 作成
% make objs # コンポーネントプログラムの *.o 作成
% make # クランチバイナリ kcopy の作成
% kcopy sh # シェル sh を起動できるかどうか試すと..
$ # うまくいった!
.fi
.Pp
ここまでくれば、バイナリ ``kcopy'' をインストールフロッピにコピーし、
各コンポーネントプログラムの名前でハードリンクを設けることができます。
.Sh 関連項目
.Xr crunchide 1
.Sh 警告
.Nm crunch
はクランチバイナリ中の各コンポーネントプログラム間のリンク競合を
除去するのに気を配っていますが、依然としてリンクされたライブラリ間で
競合が発生する可能性が残っています。
ライブラリ順の入れ換えが必要な場合もありますし、
二つのライブラリ間にどうしても解消できない競合が発生し、
結局ひとつにまとめられない場合も稀にあります。
.Pp
BSD のバージョンによっては、デフォルトのビルド環境では
単一ソースファイルのプログラムに対して
中間オブジェクトファイルを作成しないことがあります。
その場合は ``make objs'' ターゲットを用いてオブジェクトファイルを
作成するか、他の調整を施す必要があります。
.Sh 作者
.Nm crunch
は
.An James da Silva Aq jds@cs.umd.edu
によって作成されました。
.sp 0
Copyright (c) 1994 University of Maryland. All Rights Reserved.
|
