Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
GNU gcjガイド: Invoking gcj
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
- １つ以上のコンパイル済みクラスファイル(
.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