1. gcjの実行
gcj
は、
gcc
に対するフロントエンドの1つに過ぎませんので、
gccと同一のオプションを数多くサポートしています。
gccのマニュアル
Using the GNU Compiler Collection (GCC)
のOption Summaryのセクションを参照してください。
このマニュアルでは、
gcj
に固有のオプションのみを説明します。
1.1 入出力ファイル
gcj
コマンドは、
いくつかのオプションと特有のファイル名を持つという点で、
gcc
コマンドに類似しています。
以下のような入力ファイル名がサポートされています。
file.java
- Javaソースファイル。
file.class
- Javaバイトコードファイル。
file.zip
file.jar
- 1つ以上のコンパイル済みクラスファイル(
.class
)を持つアーカイブ。
アーカイブは圧縮されていることもあります。
@file
- 空白で区切られた(複数の)入力ファイル名を持つファイル
(現時点ではこれらのファイルはすべて
.java
ソースファイルでなくてはなりませんが、
将来この点については変更される可能性があります)。
名前が指定されたファイルはすべて、
コマンドライン上で指定されたかのようにコンパイルされます。
library.a
library.so
-llibname
- リンク時に使われるライブラリ。
gcc
マニュアルを参照して下さい。
gcj
コマンドライン上には複数の入力ファイルを指定することができます。
この場合、
指定されたすべてのファイルがコンパイルされます。
-o FILENAME
オプションを指定すると、
すべての入力ファイルがコンパイルされて、
FILENAMEという名前の出力ファイルが1つ生成されます。
このオプションは、
-S
オプションや-c
オプションが使われているときにも使うことができます。
しかし、
-C
オプションや--resource
オプションが使われているときには使うことはできません
(これは、
通常のgcc
では許されない拡張機能です)。
(複数の入力ファイルが指定された場合、
現在のバージョンでは、
それらはすべて.java
ファイルでなければなりません。
この点については将来修正したいと考えています。)
1.2 入力オプション
gcj
には、
必要なファイルを探す場所を制御するオプションがあります。
例えば、
gcj
は、
コンパイルするよう求められたファイルが参照しているクラスをロードする必要があるかもしれません。
他のJava言語用コンパイラと同様、
gcj
にもクラスパスという概念があります。
いくつかのオプションおよび環境変数によってこのクラスパスを操作することができます。
gcj
があるクラスを探すとき、
該当する`.class'ファイルまたは`.java'ファイルを見つけるためにクラスパスを探索します。
gcj
には組み込みのクラスパスがあり、
それはインストールされた`libgcj.jar'を指します。
このファイルにはすべての標準的なクラス群が含まれています。
以下において、
ディレクトリまたはパス要素は、
ファイルシステム上にある実際のディレクトリを指すことも、
`.zip'ファイルまたは`.jar'ファイルを指すこともできます。
gcj
は、
`.zip'ファイルや`.jar'ファイルを、
それがあたかもディレクトリであるかのように探索します。
-Idir
-I
によって指定されたすべてのディレクトリは、
そのままの順序で
他のオプションから組み立てられたクラスパスの先頭に追加されます。
javac
のようなツールとの互換性が重要ではない限り、
クラスパスを操作するときには、
他のオプションではなく常に-I
オプションを使うことをお勧めします。
--classpath=path
- クラスパスをpathにします。
pathは、
コロンで区切られたパスの一覧です
(Windowsベースのシステムでは、
セミコロンで区切られたパスの一覧です)。
これは、
組み込みサーチパス(「ブートクラスパス」)を無効にすることはありません。
--CLASSPATH=path
--classpath
と同義ですが、
推奨されません。
--bootclasspath=path
java.lang.String
のような標準組み込みクラスを見つける場所を指定します。
--extdirs=path
- pathの中の個々のディレクトリについて、
そのディレクトリ内に存在するファイルをクラスパスの終端に追加します。
CLASSPATH
- パスの一覧を保持する環境変数です。
最終的なクラスパスは以下のように組み立てられます。
-
最初に、
-I
に指定されたすべてのディレクトリが使われます。
-
`--classpath'が指定されると、
その値が追加されます。
`--classpath'が指定されていなくて、
CLASSPATH
環境変数が指定されている場合は、
その値が追加されます。
どちらも指定されていない場合はカレントディレクトリ("."
)が追加されます。
-
--bootclasspath
が指定されると、
その値が追加されます。
--bootclasspath
が指定されていないと、
組み込みのシステムディレクトリに相当する`libgcj.jar'が追加されます。
-
最後に、
--extdirs
が指定されると、
指定されたディレクトリ内に存在するファイルがクラスパスの終端に追加されます。
--extdirs
が指定されていないと、
組み込みの拡張ディレクトリ(extdir)である$(prefix)/share/java/ext
内に存在するファイルが追加されます。
gcj
によって作成された
(libgcj.jar
に格納されている)
java.lang.Object
クラスのクラスファイルには、
長さゼロの特殊なgnu.gcj.gcj-compiled
という属性情報が含まれています。
コンパイラはjava.lang.Object
をロードするときにこの属性情報を探して、
見つけることができなければエラーを報告します。
ただし、
コンパイルの出力形式がバイトコードであるときはエラーを報告しません
(-fforce-classes-archive-check
オプションを使って、
この特定のケースにおける振る舞いを無効にすることができます)。
-fforce-classes-archive-check
- コンパイラに対して、
常に
java.lang.Object
の長さゼロの特殊なgnu.gcj.gcj-compiled
属性情報をチェックさせて、
見つからない場合にはエラーを出力することを強制します。
1.3 エンコーディング
Javaプログラミング言語では一貫してUnicodeが使われます。
gcj
は、
他のロケールも適切に統合することに努めていて、
ほとんどすべてのエンコーディングを使って`.java'ファイルを書くことができます。
gcj
は、
これらのエンコーディングをコンパイル時に内部エンコーディングに変換する方法を知っています。
--encoding=NAME
オプションを使って、
ソースファイルにおいて使われている(特定の文字セットの)エンコーディングを指定することができます。
このオプションが指定されていないときは、
その時点におけるカレントロケールがデフォルトのエンコーディングとなります。
ホストシステムに十分なロケールサポートがない場合、
gcj
は、
デフォルトエンコーディングがUnicodeの`UTF-8'エンコーディングであるものと想定します。
--encoding
を実装するために、
gcj
は単に、
ホストプラットフォームのiconv
変換ルーチンを使っているだけです。
このことは、
gcj
ができることは、
そのホストプラットフォームにできる範囲に事実上限定されていることを意味しています。
--encoding
の引数に指定することのできる名前はプラットフォームによって異なります
(標準が存在しないからです)。
しかし、
gcj
は`UTF-8'という名前のエンコーディングを内部的に実装していますので、
ソースファイルにおいてこのエンコーディングを使うことにすれば、
すべてのホスト上で動作することが保証されます。
1.4 警告
gcj
はいくつかの警告を実装しています。
他の一般的なgcc
の警告と同様、
ある警告が-Wfoo
という形式のオプションによって有効になるとき、
それを無効にするには-Wno-foo
という形式を指定します。
以下においては、
効力を持つ警告の形式を記述することにしました。
すなわち、
以下の一覧に示されているものの反対がデフォルトであるということです。
-Wredundant-modifiers
- このフラグが指定されると、
gcj
は冗長な修飾子について警告を出力します。
例えば、
あるインタフェースメソッドがpublic
として宣言されていると警告を出力します。
-Wextraneous-semicolon
- 空の文に対して
gcj
に警告を出力させます。
空の文は推奨されなくなっています。
-Wno-out-of-date
- このオプションを指定すると、
ソースファイルが対応するクラスファイルよりも新しいときに
gcj
は警告を出力しなくなります。
デフォルトでは、
gcj
はこのことを警告します。
-Wunused
gcc
の-Wunused
と同じです。
-Wall
-Wredundant-modifiers -Wextraneous-semicolon-Wunused
と同じです。
1.5 コード生成
コード生成を制御するgcc
の数多くのオプションに加えて、
gcj
は固有のオプションをいくつか持っています。
--main=CLASSNAME
- このオプションは、
リンクの際に、
生成される実行可能ファイルが実行されるときに呼び出されるべき
main
メソッドを持つクラスの名前を指定するのに使われます。
(1)
-Dname[=value]
- このオプションは
--main
と組み合わせてのみ使うことができます。
これは、
valueという値を持つnameという名前のシステムプロパティを定義します。
valueが指定されていない場合、
値はデフォルトで空文字列となります。
これらのシステムプロパティはプログラムの開始時に初期化され、
実行時にはjava.lang.System.getProperty
メソッドによって値を取得することができます。
-C
- このオプションは、
オブジェクトコードではなくバイトコード(`.class'ファイル)を生成するよう
gcj
に知らせるために使われます。
--resource resource-name
- このオプションは、
実行時にコアプロトコルハンドラを使って`core:/resource-name'としてアクセスすることができるようにするために、
指定されたファイルの内容をオブジェクトコードに変換するよう
gcj
に知らせるために使われます。
resource-nameは、
実行時に見つけるときのリソース名であることに注意してください。
例えば、
その名前はResourceBundle.getBundle
に対する呼び出しにおいて使われることがあります。
このようにコンパイルされる実際のファイルの名前は別に指定されなければなりません。
-d directory
-C
と組み合わせて使われると、
生成されたすべての`.class'ファイルはdirectoryの下の適切なサブディレクトリに置かれます。
デフォルトでは、
その時点における作業ディレクトリのサブディレクトリに置かれます。
-fno-bounds-check
- デフォルトでは、
gcj
は、
配列のインデックスを指定するすべてのオペレーションにおいて境界チェックを行なうコードを生成します。
このオプションを指定すると、
これらのチェックは省略され、
配列を頻繁に使用するコードのパフォーマンスを向上させることができます。
この結果、
問題となるコードが実際に配列境界の制約に違反した場合に、
予期できない振る舞いを示す可能性があるということに注意してください。
コードが絶対にArrayIndexOutOfBoundsException
を投げることがないと確信できる場合にこのオプションを使うのが安全です。
-fno-store-check
- 配列への値の格納に際してチェックを行なうコードを生成しません。
オブジェクトを配列に格納するとき、
そのオブジェクトが配列の要素型と代入互換性があること
(このことはコンパイル時には分からない可能性があります)
を確認するために、
実行時にチェックを行なうコードが通常は生成されます。
このオプションを指定すると、
このチェックが省略されます。
これにより、
配列に頻繁にオブジェクトを格納するコードのパフォーマンスを向上させることができます。
コードが絶対に
ArrayStoreException
を投げることがないと確信できる場合にこのオプションを使うのが安全です。
-fjni
gcj
には、
ネィティブメソッドを書く方法が2つあります。
CNIとJNIです。
デフォルトでは、
gcj
はCNIが使われているものと想定します。
ネィティブメソッドを持つクラスをコンパイルする場合、
それらのメソッドがJNIによって実装されているのであれば、
-fjni
を指定しなければなりません。
このオプションを指定すると、
gcj
は、
JNIメソッドを呼び出すスタブコードを生成します。
-fno-optimize-static-class-initialization
- 最適化レベルが
-O2
以上のとき、
gcj
は、
静的クラスをそれが最初に使われたときに初期化するようランタイムを呼び出す方法を最適化しようと試みます
(この最適化は-C
が指定されているときには実行されません)。
ネィティブコードにコンパイルするときは、
使われている最適化レベルにかかわらず、
-fno-optimize-static-class-initialization
によってこの最適化は無効化されます。
1.6 コンフィグレーション時のオプション
gcj
のコード生成オプションのいくつかは、
最終的に使われるABIに影響を与えます。
したがって、
これらのオプションを指定して意味があるのは、
ランタイムパッケージであるlibgcj
のコンフィグレーションを行なうときだけです。
libgcj
は、
これらのグループの中から適切なオプションを`spec'ファイルに書き込みます。
このファイルはgcj
によって読み込まれます。
これらのオプションを以下に一覧にして示しているのは完全を期すためです。
libgcj
を使っているのであれば、
これらのオプションを操作することはしないほうが良いでしょう。
-fuse-boehm-gc
- Boehm GCのビットマップマーキングコードの使用を有効化します。
具体的には、
gcj
が個々のvtableにオブジェクトマーキング用のディスクリプタを出力するようになります。
-fhash-synchronization
- デフォルトでは、
シンクロナイゼーションデータ
(
synchronize
、
wait
、
notify
において使われるデータ)
は個々のオブジェクトの中にある1ワードのデータとして参照されます。
このオプションを指定すると、
gcj
は、
この情報がオブジェクト自身の中にではなく、
あるハッシュテーブルの中に格納されているものと想定します。
-fuse-divide-subroutine
- いくつかのシステムにおいて、
整数型の除算を実行するのにライブラリルーチンが呼び出されます。
これは、
ゼロによる除算を行なった際の例外を正しく処理するために必要とされます。
-fcheck-references
- いくつかのシステムにおいて、
リファレンス経由でオブジェクトにアクセスするところすべてにインラインチェックを行なうコードを挿入する必要があります。
他のシステムにおいては、
このようなことは必要ありません。
ヌルポインタによるアクセスはプロセッサによって自動的に捕捉されるからです。
This document was generated
by TurboLinux User on February, 6 2003
using texi2html