7.4 相互運用性

この節では、GNU C や GNU C++ を、特定のシステム上の 他のコンパイラや、アセンブラ、リンカ、ライブラリ、デバッグと共に 使う場合に出会う様々な問題を説明する。

• Objective C は、RS/6000 では動作しない。
• GNU C++ の名前のマングリング方法は、他の C++ コンパイラとは異なっている。 このため、あるコンパイラでコンパイルされたオブジェクトファイルは、 別のコンパイラでこんぱいるされたオブジェクトファイルと一緒に使うことは できない。

  これは、意図的にそうしているのである。より深刻な問題を回避するために。 C++ の実装は、コンパイラにより、内部の詳細が色々異なっている。 例えば、クラスのインスタンスの配置方法、多重継承の実装方法、それに 仮想関数の呼びだし方法などが異なっている。もし名前のエンコード方法に 同じにすると、他のコンパイラでコンパイルされたライブラリをリンクできて しまうことになる。しかし、実装方法の異なるものをリンクしたことにより、 そのプログラムは実行すると異常を起こすだろう。 名前のエンコード方法を異なるものにしておけば、互換性のないライブラリを リンクすることを、プログラムの実行時ではなく、リンク時に検出できるのである。

• GDB の古いバージョンでは、GCC のバージョン 2 の出力を正しく読めないことが ある。もし問題が起きたら、GDB のバージョン 4.4 以降を使って欲しい。
• DBX は、GCC によって生成されたファイルを受け付けない場合がある。 PCC の出力に表れる同様の構文は受け付けるのにもかかわらず。 誰かが、何が DBX の正しい入力で、何が正しくない入力なのかについて 整合性のある定義をしてくれるまで、この問題に関して出来ることは 何もない。読者は思うとおりにやれば良い。
• GNU アセンブラ(GAS)は PIC をサポートしていない。PIC コードを 生成するには、‘/bin/as’ のような、何か他のアセンブラを使う必要がある。
• Ultrix の幾つかのバージョンを含む、BSD システムの中には、 プロファイル機能を使うと、静的変数のデストラクタ(今のところ C++ でしか 使われていない)が実行されないものがある。
• ‘-I/usr/include’ という指定は何かと問題になることが多い。

  多くのシステムでは、ヘッダファイルは、fixincludes で 修正しないと GCC では使えない。修正されたヘッダファイルは 新規のディレクトリに置かれる。GCC は、‘/usr/include’ の 前にこのディレクトリを検索する。 オプション ‘-I/usr/include’ を指定すると、GCC は、 まず、正しいヘッダの前に、‘/usr/include’ を検索する。 その結果は、正しくないヘッダファイルを使うことになる。

  その場合正しくは以下のようにする(ただし、C プログラムをコンパイルする場合)。

  -I/usr/local/lib/gcc-lib/target/version/include -I/usr/include

  C++ のプログラムについては、GCC はさらに、標準 C サブルーチンへの C++ インターフェースを定義する特別なディレクトリを検索する。 このディレクトリは、他の標準インクルードディレクトリの前にに 検索することを意図しているので、他に優先する。 C++ のプログラムをコンパイルするときにインクルードディレクトリを 明示的に指定する場合には、次のオプションをまず指定し、その後に上記の 二つのオプションを指定する。

  -I/usr/local/lib/g++-include

• SGI システムの中には、オプションとして ‘-lgl_s’ を 指定すると、不思議なことに ‘-lgl_s -lX11_s -lc_s’ に 変換されてしまう。 通常、GCC を使うときにはこうならない。 三つのオプションを全て明示的に指定しなければならない。
• SPARC では、GCC は double 型の値を全て8バイト境界に 揃える。そしてあらゆる double がそのように揃っていることを 想定している。Sun のコンパイラも通常は double の値を 8バイトのアラインメントにするが、一つだけ例外がある。double 型の 関数の引数はアラインメントがとられないことがある。

  その結果、Sun CC でコンパイルした関数が double 型の引数の アドレスを取り、この double * 型のポインタを GCC でコンパイル した関数に渡すと、そのポインタを間接参照すると致命的なシグナルを 受けることになるだろう。

  これを解決する方法の一つは、プログラム全体を GCC で コンパイルすることである。もう一つの解決方法は、Sun CC でコンパイルする 関数を修正して、引数をローカル変数にコピーするようにすることである。 ローカル変数は常に正しく整合境界が取られる。 三番目の方法としては、ポインタを使って間接参照を行なっている 関数を修正して、‘*’ を使って直接的に参照する代わりに、 以下の関数 access_double を使うことである。

  inline double access_double (double *unaligned_ptr) { union d2i { double d; int i[2]; }; union d2i *p = (union d2i *) unaligned_ptr; union d2i u; u.i[0] = p->i[0]; u.i[1] = p->i[1]; return u.d; }

  ポインタへの格納も同じ共用体を使って同様に行なうことができる。

• Solaris では、‘libmalloc.a’ ライブラリ中の malloc 関数が 確保するメモリのアラインメントが 4 バイトにしかなっていない。 SPARC 用の GCC は、double 型は 8 バイトアラインメントであることを 想定しているので、この結果、double の値を ‘libmalloc.a’ ライブラリで 確保ししたメモリに格納すると、致命的なシグナルを受ける。

  解決するには、‘libmalloc.a’ ライブラリを使わないことである。 代わりに、‘libc.a’ にある malloc やその関連関数を 使えば良い。‘libc.a’ にあるものには、この問題はない。

• Sun は、SunOS の幾つかのバージョン(主に 4.1)で、 ‘libdl.a’ のスタティック版を含めるのを忘れている。 この結果、スタティックにバイナリをリンクするとき(すなわち、 ‘-static’ を指定したとき)に、未定義シンボルが出る。 リンク時に、_dlclose、_dlsym、_dlopen といった 未定義シンボルが出たら、MIT 版の X Window System から ‘mit/util/misc/dlsym.c’ を取ってきてリンクすると良い。
• SPARC 向け移植でサポートしている 128 ビットの long double 形式は、 現時点では、アーキテクチャにより定義されている 4 語長浮動小数点 命令を使うことで動作している。これらの命令をサポートしている ハードウェアは存在しないので、OS でエミュレートしなければならない。 SunOS 4.0.3 以前では long double は動作しない。 カーネルのエミュレータが古臭い、互換性のないフォーマットを使っている ためである。 SunOS 4.1.1 では、long double は、Sun のライブラリの問題により動作しない。 SunOS 4.1.2 以降では、long double は、動作するが、GCC はデフォルトでは 有効にしていない。 SunOS 5.x(Solaris 2.x) では、long double は、動作するようだ。
• HP PA 用の HP-UX バージョン 9.01 では、HP のコンパイラ cc は GCC を正しくコンパイルしない。理由はまだわからない。 ただし、以前のバージョンの HP-UX でコンパイルした GCC は HP-UX 9.01 上で 正しく動作するので、9.01 で GCC をコンパイルするのに使える。
• HP PA の機種では、GCC でコンパイルした関数については、ADB が正しく 動作しないことが時々ある。特に、alloca や可変長配列を使っている 関数の場合にうまくいかない。これは、GCC がそういう関数に対しては HP-UX のスタック巻き上げ記述子を生成しないからである。これを生成するのは 不可能にさえ思える。
• 補助ツールとして GNU のツール群を使用しない限り、HP PA の機種では デバッグ(‘-g’) はサポートされない。
• ラベルのアドレスを取ると HP-UX の PA 用アセンブラではエラーになる。 PA 用の GAS にはこの問題はない。
• 静的な関数を間接的に呼び出すときに、浮動小数点引数を使うのは、 HP のアセンブラを使う場合にはうまくいかない。 HP のアセンブラを使ったときに静的な関数への引数をどのレジスタが保持するか を GCC が指定する方法がないのである。 PA 用の GAS にはこの問題がない。
• 滅多にないことだが、関数が非常に大きい場合、HP のリンカが 無条件分岐のオフセットの範囲を越えたというエラーを出すことがある。 これは、以前の GCC で今よりよく発生していた問題だが、今では 非常に希である。この問題に出会ったら、関数を小さくすることで 回避可能である。
• GCC でコンパイルしたコードに対し、HP-UX のアセンブラから以下のような 形式の警告が出ることがある。

  (warning) Use of GR3 when frame >= 8192 may cause conflict.

  この警告は無害なので無視して大丈夫である。

• RS/6000 のアセンブラ(‘/bin/as’) の現在のバージョンにはある 問題があり、このため GCC の ‘-g’ オプションが正しく動作しない。 ‘Makefile.in’ では、‘libgcc2.c’ をコンパイルするときには デフォルトで ‘-g’ を指定している。

  IBM は修正済みのアセンブラを出している。ただし、残念なことに このアップグレードしたアセンブラは、AIX 3.2 の PTF リリース(3.2.2、 3.2.3、3.2.3e)のどれにも含まれていなかった。 AIX3.1 のユーザは PTF U403044 を、AIX3.2 のユーザは PTF U416277 を IBM に要求すること。これらの更新についての詳しい情報は ‘README.RS6000’ というファイルを参照のこと。

  修正済みのアセンブラがあるかどうかは以下のコマンドでテストできる。

  as -u < /dev/null

  このコマンドが正常に終了すれば、修正済みアセンブラがインストール済みである。 "-u" というオプションは知らないよと出たら、修正版を注文する必要がある。

• IBM RS/6000 では、

  extern int foo; … foo … static int foo;

  という形のコードをコンパイルすると、リンカが foo が 未定義シンボルであると言ってくる。これは他の多くのシステムとは 異なる動作であるが、これはバグではない。extern 変数を static として再定義することは、ANSI C では未定義であるからである。

• RS/6000 用 AIX は、合衆国外の環境(NLS) をサポートしている。 コンパイラやアセンブラは、浮動小数点数(少数部分を分けるのに "." を使うか "," を使うか)等の様々なオブジェクトのロケール固有の 表現をサポートするのにNLS を使っている。 GCC を使ってライブラリをリンクすると、アセンブラが受け付けるのと 同じ形式の浮動小数点数を生成しないという問題が報告されている。 この問題が出た場合は、環境変数 LANG を "C" または "En_US" に設定すると 良い。
• たとえ ‘-fdollars-in-identifiers’ を指定したとしても、 RS/6000 では識別子の中で ‘$’ を使えない。これは IBM のアセンブラの制限による。GAS なら問題ない。
• RS/6000 の、XLC バージョン 1.3.0.0 は ‘jump.c’ を 正しくコンパイルできない。XLC バージョン 1.3.0.1 以降は この問題が直っている。XLC-1.3.0.2 を入手するには、IBM に PTF 421749 を要求すれば良い。
• DG/UX の 5.4.2.0.1 以前のバージョンのアセンブラにはバグがあり、 ‘fldcr’ 命令を使ったときに問題が現れる。 GCC は、‘fldcr’ を、88100 上で揮発性のメモリ参照を 逐次化するのに使っている。読者のバージョンのアセンブラに このバグがあるときは、‘-mno-serialize-volatilie’ オプションを 指定すること。
• VMS では、GAS のバージョン 1.38.1 以前のバージョンを使うと、 リンカが本当ではない警告を出すことがある。この警告メッセージは、 psect 属性が一致しないと文句を言うが、無視してかまわない。 See section GNU CC を VMS にインストール。
• NewsOS バージョン 3 で、‘stddef.h’ と ‘sys/types.h’ を 両方インクルードすると、size_t の typedef が二つあるというエラー メッセージが出る。‘sys/types.h’ を 編集して、size_t の定義の前後に以下のような行を加える必要がある。

  #ifndef _SIZE_T #define _SIZE_T 実際の typedef をここに置く #endif

• Alliant では、システム固有の構造体と共用体を返す規約が普通でなく、 どのオプションを指定しても GCC とは互換性がない。
• IBM RT PC では、MetaWare HighC コンパイラ(hc)は、構造体と共用体を 返す規約が異なるものを使っている。‘-mhc-struct-return’ オプションを 使うと、GCC は hc と互換性のある規約を使う。
• Ultrix では、Fortran コンパイラはレジスタ 2 から 5 までは、 関数呼出しによりセーブされると想定している。一方、C コンパイラは BSD Unix と互換性のある規約である、レジスタ 2 から 5 までは関数呼出しに より破壊されるという規約を採用している。

  GCC は、Ultrix の C コンパイラと同じ方の規約を使っている。 以下のオプションを使うと、Fortran コンパイラと互換性のあるコードを 生成可能である。

  -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5

• WE32k では、GCC でコンパイルしたプログラムがシステムの共有 C ライブラリ とうまく動かないことがある。システムの C コンパイラでリンクする必要が あるかもしれない。その場合、以下のオプションを指定しなければならない。

  -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s

  最初に、‘-lgcc’ オプションで指定されるライブラリ ‘libgcc.a’ を 探す場所を指定する。

  GCC は、ちょうど cc が行なうのと同じように、 ld を起動することでリンクを行なっているので、ld を 起動するのにどのコンパイルプログラムを使うかが関係してくる理由は ない。誰かがこの問題の原因を突き止めれば、修正するのはおそらく 簡単だろう。

• Alpha では、アセンブラが、浮動小数点定数のために文法が正しくないという旨の エラーを出すことがある。これは、C ライブラリ関数 ecvt、 fcvt、gcvt のバグのためである。 これらの関数は、有効な浮動小数点数を指定しても、‘NaN’ を 表示するときがある。
• Irix 4.0.5Fでは(それに多分、他の幾つかのバージョンでも)、 最適化が有効になっているときに、アセンブラのバグにより命令の並べ替えが 正しく行なわれないことがある。この問題に出会ったと思われる場合は、 GNU アセンブラを試して欲しい。GAS バージョン 2.1 は Irix 上の ECOFF を サポートしている。

  あるいは、GCC 自身をコンパイルするときは ‘-noasmopt’ オプションを 指定し、読者自身のプログラムをコンパイルするときも同様にする方法が ある。(これは、Irix のアセンブラの最適化をしないようにする一時的な 小細工である。) この方法が読者にとって必要であることが判ったなら、 ‘specs’ ファイルのアセンブラ指定を書き換えて、無条件に ‘-O0’ をアセンブラに渡すようにし、‘-O2’ や ‘-O3’ は 絶対渡らないようにするのである。

This document was generated using texi2html 1.78.