RPCクライアント/サーバー・プログラムのビルド

TxRPCプログラマは、C言語コンパイル・システムとOracle Tuxedo ATMIクライアント/サーバーのビルドに精通している必要があります。Oracle Tuxedo ATMIクライアント/サーバーのビルドについては、『C言語を使用したOracle Tuxedoアプリケーションのプログラミング』、『COBOL言語を使用したOracle Tuxedoアプリケーションのプログラミング』および『FMLを使用したOracle Tuxedoアプリケーションのプログラミング』を参照してください。ワークステーション・クライアントのビルドについては、『Oracle Tuxedoワークステーション・コンポーネントの使用』を参照してください。

RPCサーバーは、ATMIリクエスト/レスポンス・サーバーとほとんど同じ方法でビルドおよび構成が行われます。実際、RPCとリクエスト/レスポンス・サーバーのサービス・ネームスペースは同じです。ただし、RPCサービス用に通知される名前は異なります。リクエスト/レスポンス・サーバーの場合、サービス名はプロシージャにマップされます。RPCサーバーの場合、サービス名はIDLインタフェース名にマップされます。通知されるRPCサービスは、<interface>v<major>_<minor>となり、<interface>はインタフェース名、<major>および<minor>は、インタフェースの定義で指定されているリリースのメジャーおよびマイナー番号(またはデフォルトの0.0)です。サービス名は127文字に制限されているため、インタフェース名の長さは13文字からリリースのメジャーおよびマイナー番号の桁数を引いた長さになります。つまり、Oracle Tuxedoシステムで行われるネーム・サービスの方法のために、メジャーおよびマイナーのリリース番号を正確に一致させることにもなります。通知は、個々の操作ではなく、インタフェースに対して行われることに注意してください(DCE/RPCに類似)。インタフェース内では正確な操作の呼出しは、サーバー・スタブによって自動的に行われます。

RPCサーバーは、buildserver(1)コマンドを使用してビルドされます。コンパイル時には、-sオプションを使用してサービス(インタフェース)名を指定することをお薦めします。こうすれば、サービスが自動的に通知されるように-Aオプションを使用して、サーバーを起動できます。付録A「サンプル・アプリケーション」で示すように、サンプル・アプリケーションではこの方法を使用しています。

buildserver(1)コマンドは、Oracle Tuxedoライブラリで自動的にリンクします。ただし、RPCランタイムは、明示的にリンクする必要があります。これは、buildserver行にあるアプリケーション・ファイルの後に-f -ltrpcオプションを指定することで行います。通常、tidl(1)コマンドの出力は、サーバー・スタブ・オブジェクト・ファイルです。これは、buildserverコマンドに直接渡すことができます。操作を実行するサーバー・スタブとアプリケーション・ソース、オブジェクトおよびライブラリのファイルは、ランタイム・ライブラリの前に、やはり-fオプションを使用して指定する必要があります。例は、付録A「サンプル・アプリケーション」のmakefile rpcsimp.mkを参照してください。

ネイティブRPCクライアントは、buildclient(1)コマンドを使用してビルドします。このコマンドは、Oracle Tuxedoライブラリで自動的にリンクします。ただし、RPCランタイムは、明示的にリンクする必要があります。これは、buildclientコマンド行にあるアプリケーション・ファイルの後に-f -ltrpcオプションを指定することで行います。通常、tidl(1)コマンドの出力は、クライアント・スタブ・オブジェクト・ファイルです。これは、buildclientコマンドに直接渡すことができます。リモート・プロシージャの呼出しを実行するクライアント・スタブとアプリケーション・ソース、オブジェクトおよびライブラリのファイルは、ランタイム・ライブラリの前に、やはり-fオプションを使用して指定する必要があります。例は、付録A「サンプル・アプリケーション」のmakefile rpcsimp.mkを参照してください。

UNIXワークステーション・クライアントをビルドするには、ネイティブ・ライブラリのかわりにワークステーション・ライブラリがリンクされるように、単に-wオプションをbuildclient(1)コマンド行に追加します。

Windows用にクライアント・スタブをコンパイルするには、コンパイル・オプションとして-D_TM_WIN定義が必要です。これにより、TxRPCおよびOracle Tuxedo ATMIランタイム関数に正しい関数プロトタイプが確実に使用されます。クライアント・スタブ・ソースが同じ場合は、DLLのテキストおよびデータ・セグメントが呼出し元のコードとは異なるものになるという事実を処理するために、特にコンパイルする必要があります。ヘッダー・ファイルおよびスタブは、C言語プリプロセッサ定義を使用して、宣言を簡単に変更できるように自動的に生成されます。定義_TMF (farのかわり)はヘッダー・ファイル内のすべてのポインタの前にあり、_TM_WINが定義されている場合、_TMFは_farとして自動的に定義されます。

ほとんどの場合、標準ライブラリを使用して、クライアントをリンクするためにbuildclient(1)コマンドを使用できます。使用されるライブラリはwtrpc.libです。

サンプルでは、クライアント・スタブを使用してダイナミック・リンク・ライブラリ(DLL)を作成する方法も示しています。この方法は、DLLの使用が必要な(アプリケーション・コードを静的にリンクできない)ビジュアル・アプリケーション・ビルダーで使用する場合には一般的です。Windowsの関数は、従来から_pascal呼出し規則を使用するように宣言されています。ヘッダー・ファイルおよびスタブは、C言語プリプロセッサ定義を使用して、宣言を簡単に変更できるように自動的に生成されます。_TMX ("eXport"用)は、すべての宣言済関数の前に置かれます。デフォルトでは、この定義は定義されていません。DLLに含めるためにスタブをコンパイルする場合、_TMXを_far _pascalとして定義する必要があります。また、DLLに含めるファイルは、ラージ・メモリー・モデルでコンパイルする必要があります。_pascalを使用すると関数はライブラリで自動的に関数名が大文字に変換されるため、-port caseオプションを有効にして実行し、宣言された名前が大文字と小文字の違いだけであることを確認するために追加の検証を行うことをお薦めします。

Windows DLLのビルドの完全な例は、付録A「サンプル・アプリケーション」を参照してください

注意:

TxRPCクライアントに windows.hが含まれている場合、uuid_t 定義の重複が原因で、コンパイル・エラーが発生する可能性があります。アプリケーションには、 windows.hを含めない(すでに含まれているため)、またはアプリケーション内の別のファイル内に含めるかのいずれかが必要になります。

クライアントおよびサーバーは、CまたはC++を使用して、互換性を持たせてビルドできます。ヘッダー・ファイルと生成されたスタブ・ソース・ファイルは、すべてのスタブ・サポート関数および生成された操作が、C++とC間で完全に相互運用できるように定義されます。これらはCリンケージにより、つまり、extern "C"として宣言され、ネーム・マングリングは無効になります。

スタブ・オブジェクト・ファイルは、tidl(1)の-cc_cmdオプションにCC -cを指定することで、C++を使用してビルドできます。CCコマンドは、buildclient(1)およびbuildserver(1)を実行する前に、CC環境変数を設定およびエクスポートすることで、クライアント・プログラムとサーバー・プログラムのコンパイルおよびリンクに使用できます。例:

Windows環境では、C++コンパイルは、通常コンパイル・コマンド行に設定したフラグや、異なるコマンド名ではなく構成オプションによって実行されます。適切なオプションを使用してC++コンパイルを実行します。

Oracle Tuxedo TxRPCコンパイラでは、OSF/DCEと同じIDLインタフェースを使用しますが、生成されるスタブでは同じプロトコルを使用しません。したがって、Oracle Tuxedo TxRPCスタブは、DCE IDLコンパイラによって生成されたスタブと直接通信できません。

ただし、DCE/RPCとOracle Tuxedo TxRPCの間では、次の相互運用が可能です。

次の項では、Oracle Tuxedo TxRPCとOSF/DCEの間で考えられる相互作用について説明します。いずれの場合も、リクエストの発信元をリクエスタと呼びます。「クライアント」のかわりにこの語を使用するのは、リクエスタが実際には、別のサービスをリクエストするDCEやOracle Tuxedo ATMIサービスの場合があるためです。「クライアント」と「サーバー」という語は、IDLコンパイラ(DCE idl(1)またはOracle Tuxedo tidl(1))によって生成されるクライアント・スタブおよびサーバー・スタブを指します。これらの語は、DCEおよびTxRPC用語との一貫性を保つために使用します。最後に、「アプリケーション・サービス」という語は、リモートで呼び出されるプロシージャを実装するアプリケーション・コードに使用されます(起動ソフトウェアがDCEまたはOracle Tuxedoのいずれによって生成されたサーバー・スタブかは通常透過的です)。

最初の方法では、Oracle Tuxedo ATMIクライアント・スタブがTxRPCを介してOracle Tuxedo ATMIサーバー・スタブを起動し、これにリンクしているDCEクライアント・スタブが(アプリケーション・サービスのかわりに)、DCE RPCを介してDCEサービスを起動するというようなゲートウェイを使用します。この方法の利点は、クライアント・プラットフォーム上にDCEがなくてもよいという点です。実際、Oracle Tuxedoを実行している一連のマシンと、DCEを実行している一連のマシンは、そのようなゲートウェイがすべて実行されている1台のマシンを別にすれば、連結していなくてもかまいません。これにより、Oracle TuxedoとDCE間でサービスを移動できる移行パスも可能になります。この方法を実装したサンプル・アプリケーションについては、付録B「DCEゲートウェイ・アプリケーション」で説明しています

この構成では、リクエスタは通常のOracle Tuxedo ATMIクライアントまたはサーバーとしてビルドされます。同様に、サーバーは通常のDCEサーバーとしてビルドされます。追加の手順では、TxRPCサーバー・スタブを使用するOracle Tuxedo ATMIサーバーと、DCE/RPCクライアント・スタブを使用するDCEクライアントの機能を果たすゲートウェイ・プロセスをビルドします。

2つのIDLコンパイラを実行し、結果のファイルをリンクするプロセスは、DCEをリンクしたOracle Tuxedo ATMIサーバーをビルドするblds_dce(1)コマンドを使用することで簡略化されます。

blds_dceの使用方法は次のとおりです。

このコマンドでは、ゲートウェイで1つ以上のインタフェースを処理できるように、1つ以上のIDLファイルを入力する必要があります。これらのファイルごとに、tidlを実行してサーバー・スタブを生成し、idlを実行してクライアント・スタブを生成します。

このコマンドは、様々なDCE環境を認識し、コンパイルおよびリンクに必要なコンパイル・フラグやDCEライブラリを提供します。新しい環境で開発する場合は、コマンドを修正して、自分の環境に合ったオプションとライブラリを追加することが必要になる可能性があります。

このコマンドは、『Oracle Tuxedo C言語関数リファレンス』で説明されているとおり、(-DTMDCEGWを定義して)メモリー割当てが常にrpc_ss_allocate(3c)およびrpc_ss_free(3c)を使用して行われるように、ソース・ファイルをコンパイルします。これにより、Oracle Tuxedo ATMIサーバーから戻るとメモリーが確実に解放されます。-DTMDCEGWを使用すると、Oracle Tuxedo TxRPCヘッダー・ファイルのかわりにDCEヘッダー・ファイルも含まれます。

IDL出力オブジェクト・ファイルは、オプションで指定したアプリケーション・ファイルとともにコンパイルされ(-fおよび-lオプションを使用)、buildserver(1)を使用してOracle Tuxedo ATMIサーバーが生成されます。実行可能サーバーの名前は、-oオプションにより指定できます。

この構成を実行すると、まずDCEサーバーがバックグラウンドで起動し、次にDCEゲートウェイを含むOracle Tuxedo構成が起動して、リクエスタが実行されます。DCEゲートウェイはシングルスレッドであるため、同時に実行するサービスと同じ数のゲートウェイ・サーバーを構成して起動する必要があります。

このゲートウェイをビルドする際には、考慮すべき選択事項がいくつかあります。

まず、DCEクライアントとして、プロセスはDCEプリンシパルとして実行されるのが普通です。ログイン・コンテキストを取得するには、2つの方法があります。1つ目の方法は、DCEへのログインです。一部の環境では、オペレーティング・システムにログインするだけで、この状態が発生します。多くの環境では、dce_loginの実行が必要です。Oracle Tuxedo ATMIサーバーはローカル・マシンで起動され、その後dce_loginの実行、tmboot(1)の実行が可能になり、起動されたサーバーはログイン・コンテキストを継承します。サーバーがリモート・マシン上でtlisten(1)を介して間接的に起動される場合、tlistenを起動する前に、dce_loginを実行する必要があります。これらのいずれの場合にも、そのセッションで起動されるサーバーはすべて、同じプリンシパルによって実行されます。この方法には、資格証明が最終的に期限切れになるという欠点があります。

もう1つの方法は、プロセスを設定し、独自のログイン・コンテキストを維持することです。サーバーに提供されているtpsvrinit(3c)関数は、コンテキストを設定し、ログイン・コンテキストを期限切れになる前にリフレッシュするスレッドを起動できます。これを行うためのサンプル・コードは、 $TUXDIR/lib/dceserver.cにあります。単純なtpsvrinit()関数を生成するには、これを-DTPSVRINITオプションを指定してコンパイルする必要があります。(次の項で説明されているように、DCEサーバー用のmain()として使用することもできます。)このコードについては、付録B「DCEゲートウェイ・アプリケーション」でさらに詳しく説明されています

Oracle Tuxedo TxRPCでは、バインド・ハンドルはサポートされていません。リクエスタのクライアント・スタブからゲートウェイ内のサーバー・スタブにRPCを送信するとき、Oracle Tuxedoシステムでは、すべての名前の解決を処理し、使用可能なサーバー間でのロード・バランシングを行いながら、サーバーを選択します。ただし、ゲートウェイからDCEサーバーへの送信の場合は、DCEバインドを使用できます。この場合、2つのバージョンのIDLファイルを同じディレクトリ内で使用するか、2つの異なるディレクトリを使用してリクエスタとゲートウェイおよびサーバーをビルドすることをお薦めします。2つの異なるファイル名を使用する前者の方法は、IDLファイルがもう1つの名前にリンクされている例で示されています。最初のIDLファイルでは、バインド・ハンドルまたはバインド属性は指定されていません。ゲートウェイとDCEサーバーの生成に使用される2つ目のIDLファイルには、ACFファイルが関連付けられていて、バインド・ハンドルが操作の最初のパラメータとして挿入される[explicit_handle]を指定します。ゲートウェイ内のOracle Tuxedoサーバー・スタブからは、NULLハンドルが生成されます(ハンドルがサポートされていないため)。つまり、ゲートウェイ内のOracle Tuxedo ATMIサーバー・スタブとDCEクライアント・スタブ間のどこかで、有効なバインド・ハンドルを生成する必要があるということです。

これは、マネージャ・エントリ・ポイント・ベクトルを使用すればできます。デフォルトでは、IDLコンパイラがインタフェースにおける操作ごとに、関数ポインタ・プロトタイプで構造体を定義し、操作名に基づいたデフォルトの関数名で構造変数を定義し、初期化します。構造体は次のように定義されます。

<INTERF>はインタフェース名、<major>_<minor>はインタフェースのバージョンです。この変数は、サーバー・スタブ関数の呼出し時に修飾参照されます。IDLコンパイラの-no_mepvオプションを指定すると、この変数の定義および初期化が禁止され、関数名と操作名で競合または違いがある場合には、アプリケーションで変数を指定できます。アプリケーションで自動バインドではなく明示的または暗黙的バインドを行う必要がある場合、-no_mepvオプションを指定して、パラメータが操作と同じで、名前が異なる(または静的な)関数を指す構造体の定義を、アプリケーションで指定できます。この関数により有効なバインド・ハンドルを作成でき、これが明示的または暗黙的にDCE/RPCクライアント・スタブ関数に(実際の操作名を使用して)渡されます。

これは、付録B「DCEゲートウェイ・アプリケーション」の例で示されています。dcebind.cファイルによりバインド・ハンドルが生成され、エントリ・ポイント・ベクトルおよび関連付けられた関数はdceepv.cに示されています。

blds_dceを使用する際に-no_mepvオプションを指定するには、-i -no_mepvオプションを指定して、オプションをIDLコンパイラに渡す必要があります。これは、付録B「DCEゲートウェイ・アプリケーション」のmakefile、rpcsimp.mkで示されています。

ログイン・コンテキストとハンドルを設定したので、認証済RPC呼出しを使用することができます。バインド・ハンドルの設定の一部として、『Oracle Tuxedo C言語関数リファレンス』で説明されているように、rpc_binding_set_auth_info()を呼び出して、認証用のバインド・ハンドルに注釈を付けることもできます。これは、付録B「DCEゲートウェイ・アプリケーション」のdcebind.cでのバインド・ハンドル生成の一部として示されています。これによりゲートウェイとDCEサーバー間の認証(および場合によっては暗号化)を設定します。リクエスタがOracle Tuxedo ATMIサーバーの場合は、Oracle Tuxedo管理者として実行することが保証されます。Oracle Tuxedoクライアントの認証の詳細は、Oracle Tuxedoシステムの管理を参照してください。

OSF/DCEではトランザクションはサポートされていません。つまり、リソース・マネージャのあるグループでゲートウェイが実行されていて、RPCがトランザクション・モードでOracle Tuxedo ATMIクライアント・スタブで受信された場合、そのトランザクションはDCEサーバーに送信されません。解決策はないため、ただそのことを認識しておいてください。

この図では、DCEリクエスタがDCEクライアント・スタブを使用してDCEサービスを起動し、DCEサービスが(アプリケーション・サービスのかわりに)Oracle Tuxedo ATMIクライアント・スタブを呼び出し、これがOracle Tuxedo ATMIサービスを(TxRPCを介して)呼び出しています。この構成では、クライアントがDCEバインドおよび認証を完全に制御していることに注意してください。アプリケーション・プログラマが中間サーバーをビルドするということは、アプリケーションによりDCEサーバーのOracle Tuxedo ATMIサービスへのバインドも制御されるということです。この方法は、DCEリクエスタがOracle Tuxedoシステムに直接リンクして呼び出す必要のない場合に使用されます。

DCEサーバー用のmain()は、$TUXDIR/lib/dceserver.cで提供されているコードをベースにする必要があります。すでにDCEサーバーのmain()用に独自のテンプレートがある場合は、いくつか追加や修正が必要になる可能性があります。

まず、tpinit(3c)を呼び出し、ATMIアプリケーションを結合する必要があります。アプリケーションのセキュリティが構成されたら、TPINITバッファで、ユーザー名やアプリケーション・パスワードなどの追加情報が必要になる可能性があります。終了する前に、tpterm(3c)を呼び出し、ATMIアプリケーションへの参加を完全に終了します。dceserver.cを見れば、それを-DTCLIENTを指定してコンパイルした場合、tpinitおよびtptermを呼び出すコードが含まれることがわかります。TPINITバッファを設定するコードは、自分のアプリケーションに合せて修正する必要があります。管理に関してより多くの情報を提供するには、クライアントがDCEクライアントであることを、ユーザー名またはクライアント名のいずれかで示すのが有効です(例ではクライアント名をDCECLIENTに設定しています)。この情報は、管理インタフェースからクライアント情報を出力すると表示されます。

次に、Oracle Tuxedo ATMIシステム・ソフトウェアはスレッドセーフではないため、rpc_server_listenに渡されるスレッド・レベルを1に設定する必要があります。サンプルのdceserver.cでは、-DTCLIENTを指定してコンパイルした場合、スレッド・レベルは1に設定され、そうでない場合は、デフォルトのrpc_c_listen_max_calls_defaultに設定されます。(詳細は、『Oracle Tuxedo C言語関数リファレンス』を参照してください。)

この構成では、リクエスタは通常のDCEクライアントまたはサーバーとしてビルドされます。同様に、サーバーは通常のOracle Tuxedo ATMIサーバーとしてビルドされます。追加の手順では、TxRPCクライアント・スタブを使用するOracle Tuxedo ATMIクライアントと、DCE/RPCサーバー・スタブを使用するDCEサーバーの機能を果たすゲートウェイ・プロセスをビルドします。

2つのIDLコンパイラを実行し、結果のファイルをリンクするプロセスは、DCEをリンクしたOracle Tuxedo ATMIクライアントをビルドするbldc_dce(1)コマンドを使用することで簡略化されます。

bldc_dceの使用方法は次のとおりです。

このコマンドでは、ゲートウェイで1つ以上のインタフェースを処理できるように、1つ以上のIDLファイルを入力する必要があります。これらの各ファイルに、tidlを実行してクライアント・スタブを生成し、idlを実行してサーバー・スタブを生成します。

このコマンドは様々なDCE環境を認識し、必要なコンパイル・フラグやDCEライブラリを提供します。新しい環境で開発する場合は、コマンドを修正して、自分の環境に合ったオプションとライブラリを追加することが必要になる可能性があります。ソースは、(-DTMDCEGWを定義して)メモリー割当てが常にrpc_ss_allocateおよびrpc_ss_freeを使用して行われ(『Oracle Tuxedo C言語関数リファレンス』で説明)、戻るとメモリーが確実に解放されるようにコンパイルされます。-DTMDCEGWを使用すると、Oracle Tuxedo TxRPCヘッダー・ファイルのかわりにDCEヘッダー・ファイルも含まれます。

IDL出力オブジェクト・ファイルは、オプションで指定したアプリケーション・ファイルとともにコンパイルされ(-fおよび-lオプションを使用)、buildclient(1)を使用してOracle Tuxedo ATMIクライアントが生成されます。含まれるファイルの1つは、-DTCLIENTオプションでコンパイルされたdceserver.oと同等のものであることが必要です。

実行可能クライアントの名前は、-oオプションで指定できます。

この構成を実行する際、Oracle Tuxedo ATMI構成は、DCEリクエストのリスニングの前にOracle Tuxedo ATMIアプリケーションを結合できるように、DCEサーバーの起動前に起動する必要があります。

この方法では、DCE環境をクライアントが直接使用可能であると想定します(これは一部の構成では、制限または不利になる可能性があります)。クライアント・プログラムは、DCEバインドおよび認証を直接制御します。これはたぶん、リクエスタがDCEサービスを呼び出すOracle Tuxedo ATMIサービスか、Oracle TuxedoサービスおよびDCEサービスの両方を呼び出すOracle Tuxedoクライアント(またはサーバー)かの混在環境です。

DCEコードと一緒に使用されるOracle Tuxedo TxRPCコードをコンパイルする際、コードは、TxRPCヘッダー・ファイルのかわりにDCEヘッダー・ファイルが使用されるようにコンパイルする必要があります。これは、コンパイル時にクライアントおよびサーバー・スタブ・ファイルと、アプリケーション・コードの両方に-DTMDCEを定義することによって行われます。tidl(1)からオブジェクト・ファイルを生成する場合、コマンド行に-cc_opt -DTMDCEオプションを追加する必要があります。別の方法は、次の例のように、IDLコンパイラからc_sourceを生成し、このCソース(オブジェクト・ファイルではない)をbldc_dceまたはblds_dceに渡します。

この例では、ゲートウェイ・プロセスをビルドしないので、.idlファイルはbuildコマンドに指定できません。また、blds_dceコマンドでは、サーバーに関連付けられたサービス名がわからないので、-sオプションを使用してコマンド行で指定する必要があります。

この最後の例では、DCEリクエスタがOracle Tuxedoクライアント・スタブを直接呼び出します。

ここでも、コンパイル時にクライアントおよびサーバー・スタブ・ファイルと自分のアプリケーション・コードの両方に対して、-DTMDCEを使用する必要があります。この場合、リクエスタはOracle Tuxedo ATMIクライアントです。

dceserver.cは、tpinit(3c)を呼び出して、アプリケーションとtpterm(3c)を結合し、前述のようにアプリケーションを終了します。

この項では、bldc_dce(1)またはblds_dce(1)コマンドを使用せずに、混在するクライアントまたはサーバーをコンパイルする場合に従う規則について要約しています。

•

生成されたクライアントおよびサーバー・スタブをコンパイルし、tidl(1)によって生成されるヘッダー・ファイルを含むクライアントおよびサーバー・アプリケーション・ソフトウェアをコンパイルする際、TMDCEを定義する必要があります(-DTMDCE=1など)。これにより、Oracle Tuxedo TxRPCヘッダー・ファイルのかわりに、いくつかのDCEヘッダー・ファイルが使用されます。また、一部のバージョンのDCEには、DCEコンパイル・シェルがあり、DCEヘッダー・ファイル用の適切なディレクトリを追加し、ローカル環境に対してDCEを適切に定義します。直接Cコンパイラを使用するかわりに、このシェルを使用します。DCE/RPCコンパイラおよびTMDCEの定義は、tidlで -cc_cmdオプションを使用して指定できます。例:

simp_cstub.oがtidl(1)によって生成され、dce_cstub.oがidlによって生成されたと想定します。最初の例では、DCEコンパイラ・シェルなしでのクライアントのビルドを示しています。この場合、DCEライブラリ(-ldce)、スレッド・ライブラリ(-lpthreads)およびリエントラントCライブラリ(-lc_r)は明示的に指定する必要があります。2つ目の例は、必要なライブラリを透過的に組み込むDCEコンパイラ・シェルの使用方法を示しています。一部の環境では、buildserverおよびbuildclientによってネットワークおよびXDR用に組み込まれるライブラリが、DCEコンパイラ・シェルによって組み込まれるライブラリと競合します(これらのライブラリのリエントラント・バージョンが存在することがあります)。この場合、buildserver(1)およびbuildclient(1)ライブラリを、-dオプションを使用して変更できます。リンクの問題が発生した場合は、前述の例に示したように、-d " "を使用してネットワークおよびXDRライブラリを省略してみてください。それでもリンクが失敗する場合は、-dオプションを指定せず-v オプションを使用してコマンドを実行し、デフォルトで使用されるライブラリを特定してください。次に、ライブラリが複数ある場合は、-dオプションを使用してライブラリのサブセットを指定します。ネットワーク、XDRおよびDCEライブラリは環境ごとに変わるため、ライブラリの正しい組合せは環境に依存します。