未解決の外部シンボル： @12 vs @8シンボル名の最後に

Question

C ++の重要な経験はありませんが、最近C ++パーツ（実際にはApacheモジュール）を使用してプロジェクトに関与する必要がありました。

今、私は既存の非常に多くのレガシーコードを構築しようとしています、VC ++リンカーが見つからない場合、非常に奇妙な問題に直面しています 1つの特定の関数 Apacheライブラリで（残りの部分を見ている間）。

このコードはこのようなものです（この問題に取り組むために特別に構築された些細なサンプルから取られたように）：

ap_rputs(ap_gm_timestr_822(r->pool, time(NULL)), r);

（これは現在の日付を印刷するだけですが、それは実際にはそれほど重要ではありません）

そして、私が得ているエラーは次のとおりです。

error LNK2019: unresolved external symbol _ap_gm_timestr_822@12 referenced in function _hello_handler

今、奇妙な部分に：この関数は実際に私がリンクしているライブラリに存在しますが、そのシンボル名はあります _ap_gm_timestr_822@8 （いいえ @12, 、 しかし @8 最後に）。

残念ながら、私はMSVC ++のほぼすべての可能なコンパイラ /リンカープロパティを使用しようとしました。

この問題は、ライブラリ（Apache 1.3 Distributionの一部）が私が使用しているものとは異なる / ... ...コンパイラで構築されているという事実に関連している可能性がありますか？私は現在、MS VC ++ Express 2008を使用しています。もしそうなら、誰かがこの問題を回避するために何ができるかについての考えを持っていますか？

Answer 1

Time_t Typedefには、Y2K38の問題と64ビットを作成するレガシー32ビットの2つのフレーバーがあり、その問題の解決策があります。ここでミスマッチがあります。

使用するCRTのHeaderファイルを確認してください。レガシーと64ビットバージョンの間で選択する#ifdefが含まれている必要があります。 2038年までにプログラマーになることを期待している場合は、レガシーの使用を避けてください。

Answer 2

Visual Studioでは、 @接尾辞は引数の合計バイトサイズを示します。 2つの関数間で異なるという事実は、署名の不一致を意味します。おそらく、サイズの違いを考えると、64ビットの32ビット関数にリンクしようとしています。

Answer 3

これらのメイクアップ名は、関数の名前と引数のタイプの詳細を組み合わせたものです。

したがって、あなたが含めているヘッダーファイルは、あなたがリンクしているLIBと一致しない引数で関数を宣言します。

コンパイラコマンドラインで「-define」が間違っているときにこれを最も頻繁にヒットするため、リブと一致しないヘッダーファイルにオプションを選択します。多くの場合、これは必要な「スレッド」を選択すること、またはUnicodeが必要な場合です。

コンパイラコマンドラインがリンカーコマンドラインに正しく一致するかどうかを確認してください。