共有ライブラリを構築するCプロジェクトから特定の関数と構造体を選択的にエクスポートするクロスプラットフォームの方法はありますか?
特定のビルドシステムを必要としない方法(可視性は、マクロなどのコードで定義する必要があります)で、GCCとMSVCの両方が理解できる方法で実行したいと思います。
ありがとうございました。
共有ライブラリを構築するCプロジェクトから特定の関数と構造体を選択的にエクスポートするクロスプラットフォームの方法はありますか?
特定のビルドシステムを必要としない方法(可視性は、マクロなどのコードで定義する必要があります)で、GCCとMSVCの両方が理解できる方法で実行したいと思います。
ありがとうございました。
もちろん、ツールチェーンは同じではないため、厳密にはありません。
しかし、人々はこれを行います。複雑な点は、Windowsでは、DLLからエクスポートする関数の宣言に、関数が定義さ__declspec(dllexport)
れているライブラリ内の場所と、関数が参照されているクライアントコード内の場所にタグを付ける必要があることです。標準のCプラクティスでは、単一のヘッダーファイルに宣言が1つしかないため、これは通常、両方の場所で機能する単一のプレフィックスを持つために、いくつかのマクロ作業を行う必要があることを意味します。すべてのプロジェクトがこれに対して独自の基準を選択しているようです。__declspec(dllimport)
Unix側では、エクスポートにタグを付ける必要はまったくありません。これは素晴らしいことです。これは、すべての非静的関数がデフォルトでエクスポートされるためですが、これはあまり良いことではありません。多くの場合、非公開/非静的シンボルに適切なプレフィックスが付いている限り、これを回避できます。これは、ほとんどのプロジェクトで行われているようです。エクスポートされたシンボルをより細かく制御する必要がある場合は、Solarisスタイルの「mapfile」とGNUリンカーの--version-script(solarisでは-M)引数を使用して、外部名前空間に表示するシンボルを明示的に定義できます。
ライブラリごとのグローバル名前空間の動作方法や起動/シャットダウンコードの処理など、プラットフォーム間にはさらにいくつかの落とし穴があります。基本的に、この短い投稿ではまともな説明ができないネズミの巣ですが、ライブラリに単純な関数が含まれ、名前空間が汚染されないように注意する限り、それほど問題はありません。ガイダンスについては、より人気のあるクロスプラットフォーム共有ライブラリ(Qt、Glib / Gtk +、msysで配布されるものなど)のいくつかを参照してください。