かなり大きな静的ライブラリ (社内で開発) をコンパイルおよびリンクしようとすると、多くの奇妙な LNK2001 および LNK2019 エラーが発生します。事実は次のとおりです。
- いくつかの静的ライブラリ (ほとんどが社内で構築されたもの) があり、すべてが一般消費用の 1 つの大きなラッパー静的ライブラリにコンパイルされています (「Pimpl」イディオム)。基本的に、ライブラリ
A、B、およびCすべてが と呼ばれる内部/プライベート ライブラリにコンパイルされていDます。D次に、と呼ばれるラップアラウンド外部/パブリック lib がありますE。 - 最終製品は実行可能ファイルではなく、Adobe Illustrator のプラグインです。
PluginMain()プラグインは基本的に、いくつかの特別なリソースと特別なエントリ ポイント (関数)を持つ単なる DLLです。/INCLUDEオプションを使用して、PluginMain常にエクスポートする必要があることを指定するまで、コンパイルとリンクはうまく機能します。 - プラグインの作成と lib へのリンクは正常に
D機能します (エラーはまったく発生しません)。プラグインを作成して lib にリンクすると、E100 を超える未解決のシンボル エラー (にあるはずのシンボルE) が発生します。 - ファイルを実行する
DUMPBINと、プラグインを作成しようとしたときにリンカーが文句を言っているすべてのシンボルが含まれているように見えます。ただし、...からのすべての出力構文を理解しているかどうかは完全にはわかりません。E.libDUMPBIN - ライブラリはすべてクロスプラットフォームであり、Mac 上の GCC/LLVM で問題なくコンパイルおよびリンクされます。
リンカーが文句を言う関数のほとんどは、単純な関数または静的メンバー関数のいずれかです。それらのほとんどは、コンパイラがインライン化しようとする可能性のある関数のように疑わしく見えます。最適化や自動インライン化を無効にしようとしましたが、同じリンク エラーが引き続き発生します。
問題を解決する可能性のあるコンパイルおよび/またはリンク設定の方向を教えてもらえますか? このような状況で一般的に誤って構成されている設定は?
おそらく、リンク時にリンカーがこれらのシンボルをエクスポートしない原因となっている、私が見逃した設定がありEますか? おそらく、リンク時にリンカがすべてのシンボルをエクスポートするように強制する設定があり、Eそれを試すことができますか? libシンボルを調べて手がかりを得るのに役立つユーティリティが存在する可能性がありますか？
私はすべてを試したように感じますが、尋ねるのは決して悪いことではありません. 皆さんありがとう。
編集 1: snowdude が実際のリンク エラーを要求しました:
E.lib(PathArt.cpp.obj) : error LNK2001: unresolved external symbol "private: __thiscall E::PathSegPoint::PathSegPoint(struct D::PathSegPoint const &)" (??0PathSegPoint@E@@AAE@ABU0D@@@Z)
内部/プライベート オブジェクトからE::PathSegPoint::PathSegPoint(const D::PathSegPoint&)外部/パブリック消費可能オブジェクトを構築するためのプライベート コンストラクターであることを追加する必要があります。繰り返しますが、これは「Pimpl」イディオムです。一部のクラス/関数は、この種の構築を可能にするためのフレンドです。E::PathSegPointD::PathSegPointE::PathSegPoint