1

私はMSVC++6を使用して非常に大きなプロジェクトを構築しています。このプロジェクトのソースファイルの一部は、アプリケーションの保守に使用する小さなユーティリティと共有されています。以前は、この小さなユーティリティには、メインアプリからの多くのライブラリに対するリンクが必要であり、実行時にメインアプリのDLLも必要でした。私はこれらの依存関係を削除する必要がありましたが、これは非常に単純に聞こえました...残念ながら、メインアプリで使用されるプリコンパイル済みヘッダーが多くの問題を引き起こしています。

最初にユーティリティ内のすべてのファイルを作り直して、必要なものをすべて明示的に含め、次にPCHの#includeディレクティブを削除しました(これにより、ユーティリティの不要な依存関係の95%が削除されました)。これは、ユーティリティのコンパイルに最適です。ただし、メインアプリをコンパイルすると、プリコンパイル済みヘッダーディレクティブが見つからないというエラーが発生します。「素晴らしい、条件付きでPCHを含める」と思いました。これは機能していないようです...ここで説明したように、「予期しない#endif」が発生します。私の次の考えは、ユーティリティとメインアプリの間で共有される3つのソースファイルのメインアプリでPCHをオフにすることでした。これは正常にコンパイルされますが、リンク中に次のようなエラーが発生します。

tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length@RWCString@@QBEIXZ) already defined in stripledescypher.obj

AFAICT、複数定義されたシンボルはすべて、PCHの必要性を回避するために、共有ファイルに明示的に含めるシンボルです。私の勘では、これら3つのファイルをPCH .cppファイルと同じDLLにリンクしているため、複数の場所でコンパイルされます。この混乱から抜け出す方法はありますか?何でもやってみます...

4

1 に答える 1

1

コンパイラーがコンパイル単位の処理中にシンボルXの定義を見つけると、リンカーのヒントが作成されます。Xはここにあります。

2つのソースファイルをコンパイルすると、両方とも定義#include付きのヘッダー(つまり、単なる宣言ではない)を使用して、同じシンボルを定義する2つのオブジェクトファイルが作成されます。リンカは、複数定義されたシンボルを見つけます。

したがって、stripledescypherオブジェクトファイルにはWCString::lenght()constメソッドの定義が含まれているようです。これは、関数本体がクラスのヘッダーなどで定義されていることが原因である可能性があります。

于 2009-07-07T19:16:34.787 に答える