typeinfoへのg ++​​未定義参照

私は次のエラーに遭遇しました（そして解決策はオンラインで見つかりましたが、Stack Overflowにはありません）。

（.gnu.linkonce。[stuff]）：[メソッド] [オブジェクトファイル]への未定義の参照:(。gnu.linkonce。[stuff]）： `[クラス名]のtypeinfoへの未定義の参照 '

これらの「typeinfoへの未定義の参照」リンカーエラーの1つが表示されるのはなぜですか？

（舞台裏で何が起こっているかを説明できる場合のボーナスポイント。）

考えられる理由の1つは、仮想関数を定義せずに宣言しているためです。

同じコンパイル単位で定義せずに宣言すると、それは別の場所で定義されていることを示します。これは、リンカーフェーズが他のコンパイル単位（またはライブラリ）の1つでそれを見つけようとすることを意味します。

仮想関数を定義する例は次のとおりです。

virtual void fn() { /* insert code here */ }

この場合、宣言に定義をアタッチしています。つまり、リンカは後で定義を解決する必要はありません。

この線

virtual void fn();

fn()それを定義せずに宣言し、あなたが尋ねたエラーメッセージを引き起こします。

それはコードに非常に似ています：

extern int i;
int *pi = &i;

これは、整数iがリンク時に解決する必要がある別のコンパイル単位で宣言されているpiことを示しています（それ以外の場合は、そのアドレスに設定できません）。

これは、ミックス-fno-rttiして-frttiコーディングするときにも発生する可能性があります。次にtype_info、-frttiコードでアクセスされるすべてのクラスが、でコンパイルされたキーメソッドを持っていることを確認する必要があります-frtti。このようなアクセスは、クラスのオブジェクトを作成したり、使用しdynamic_castたりするときに発生する可能性があります。

[ ソース ]

これは、宣言された（純粋でない）仮想関数のボディが欠落している場合に発生します。クラス定義では、次のようになります。

virtual void foo();

定義する必要があります（インラインまたはリンクされたソースファイル内）：

virtual void foo() {}

または純粋仮想を宣言しました：

virtual void foo() = 0;

gccマニュアルからの引用：

ポリモーフィッククラス（仮想関数を持つクラス）の場合、type_infoオブジェクトはvtableとともに書き出されます[...]他のすべてのタイプの場合、type_infoオブジェクトが使用されるときに書き出されます。式に「typeid」を適用すると、オブジェクトをスローするか、catch句または例外仕様で型を参照します。

そして、同じページの少し前に：

クラスが非インライン、非純粋仮想関数を宣言している場合、最初の関数がクラスの「キーメソッド」として選択され、vtableはキーメソッドが定義されている翻訳単位でのみ出力されます。

そのため、このエラーは、他の回答がすでに述べたように、「キーメソッド」の定義が欠落している場合に発生します。

.soを別の.soにリンクする場合、もう1つの可能性は、gccまたはg ++で「-fvisibility = hidden」を使用してコンパイルすることです。両方の.soファイルが「-fvisibility = hidden」でビルドされ、キーメソッドが別の仮想関数の実装と同じ.soにない場合、後者は前者のvtableまたはtypeinfoを認識しません。リンカにとって、これは実装されていない仮想関数のように見えます（paxdiabloやcdlearyの回答のように）。

この場合、基本クラスの可視性を次のように例外にする必要があります

__attribute__ ((visibility("default")))

クラス宣言内。例えば、

class __attribute__ ((visibility("default"))) boom{
    virtual void stick();
}

もちろん、別の解決策は、「-fvisibility = hidden」を使用しないことです。これはコンパイラとリンカにとって複雑なことであり、コードのパフォーマンスを損なう可能性があります。

上記の答えは正しいですが、このエラーは、仮想関数を持たないクラスのオブジェクトでtypeidを使用しようとした場合にも発生する可能性があります。C ++ RTTIにはvtableが必要であるため、型の識別を実行するクラスには少なくとも1つの仮想関数が必要です。

型情報が仮想関数を実際に必要としないクラスで機能するようにしたい場合は、デストラクタを仮想にします。

私はこのエラーに数時間費やしましたが、ここでの他の回答は何が起こっているのかを理解するのに役立ちましたが、それらは私の特定の問題を解決しませんでした。

私は両方を使用してコンパイルしたプロジェクトに取り組んでいますclang++とg++。を使用してリンクの問題はありませんclang++でしたが、でundefined reference to 'typeinfo forエラーが発生していましたg++。

重要なポイント：順序の重要性とのリンクg++。リンクするライブラリを間違った順序でリストすると、typeinfoエラーが発生する可能性があります。

/ とのリンク順序の詳細については、このSOの質問を参照してください。gccg++

RTTIおよび非RTTIライブラリを扱うコードの可能な解決策：

a）-frttiまたは-fno-rttiのいずれかを使用してすべてを再コンパイルします。b
）a）が不可能な場合は、以下を試してください。

libfooがRTTIなしで構築されていると仮定します。コードはlibfooを使用し、RTTIでコンパイルします。virtualsを持つlibfooでクラス（Foo）を使用すると、リンク時のエラーが発生する可能性があります。クラスFooのtypeinfoがありません。

仮想を持たず、使用するFooに呼び出しを転送する別のクラス（FooAdapterなど）を定義します。

RTTIを使用せず、libfooシンボルにのみ依存する小さな静的ライブラリでFooAdapterをコンパイルします。ヘッダーを提供し、コード（RTTIを使用）で代わりに使用します。FooAdapterには仮想関数がないため、typeinfoはなく、バイナリをリンクできます。libfooのさまざまなクラスをたくさん使用する場合、このソリューションは便利ではないかもしれませんが、それは出発点です。

上記のRTTI、NO-RTTIの説明と同様に、この問題は、dynamic_castを使用していて、クラス実装を含むオブジェクトコードを含めなかった場合にも発生する可能性があります。

CygwinでビルドしてからコードをLinuxに移植するこの問題に遭遇しました。makeファイル、ディレクトリ構造、およびgccバージョン（4.8.2）も両方のケースで同じでしたが、コードはCygwinで正しくリンクおよび動作しましたが、Linuxではリンクできませんでした。Red Hat Cygwinは、オブジェクトコードのリンク要件を回避するコンパイラ/リンカーの変更を行っているようです。

Linuxリンカーのエラーメッセージは、適切にdynamic_cast行に誘導しましたが、このフォーラムの以前のメッセージでは、実際の問題ではなく、不足しているオブジェクトのコードではなく、不足している関数の実装を探していました。私の回避策は、dynamic_castを使用するのではなく、ベースおよび派生クラスの仮想型関数（たとえば、仮想int isSpecialType（））を置き換えることでした。この手法により、dynamic_castが適切に機能するようにするためだけにオブジェクト実装コードをリンクする必要がなくなります。

基本クラス（抽象基本クラス）では、仮想デストラクタを宣言します。デストラクタを純粋な仮想関数として宣言することはできないため、抽象クラスでここで定義する必要があります。virtual〜base（ ）{}は、または派生クラスのいずれかで行います。

これを行わないと、リンク時に「未定義のシンボル」になります。VMTには、派生クラスの実装に応じてテーブルを更新するときに、一致するNULLを持つすべての純粋仮想関数のエントリがあるためです。ただし、純粋ではないが仮想関数の場合は、VMTテーブルを更新できるように、リンク時に定義が必要です。

c ++ filtを使用してシンボルをデマングルします。$ c ++ filtのように、_ZTIN10storageapi8BaseHostEは「typeinfo for storageapi :: BaseHost」のようなものを出力します。

たった今、これらのエラーがたくさん発生しました。何が起こったのか、ヘッダーファイルのみのクラスをヘッダーファイルとcppファイルに分割しました。ただし、ビルドシステムを更新しなかったため、cppファイルはコンパイルされませんでした。ヘッダーで宣言されているが未実装の関数への未定義の参照があるだけで、これらのtypeinfoエラーがたくさん発生しました。

解決策は、ビルドシステムを再実行して、新しいcppファイルをコンパイルおよびリンクすることでした。

私の場合、ヘッダーファイルなどを含むサードパーティのライブラリを使用しました。1つのクラスをサブクラス化し、サブクラスをインスタンス化しようとすると、このようなリンクエラーが発生しました。

@sergiyによって言及されたように、「rtti」の問題である可能性があることを知っていたので、コンストラクターの実装を別の.cppファイルに入れ、「-fno-rtti」コンパイルフラグをファイルに適用することで回避できました。それはうまくいきます。

このリンクエラーの内部についてはまだはっきりしていませんので、私の解決策が一般的かどうかはわかりません。ただし、@ francoisで言及されているアダプターの方法を試す前に、一撃の価値があると思います。もちろん、すべてのソースコードが利用できる場合（私の場合ではありません）、可能であれば '-frtti'で再コンパイルすることをお勧めします。

もう1つ、私のソリューションを試すことを選択した場合は、別のファイルをできるだけ単純にして、C ++のいくつかの凝った機能を使用しないようにしてください。ブーストに関連することに特に注意してください。原因の多くはrttiに依存しています。

インターフェース（すべての仮想関数を含む）にもう1つの関数が必要で、「null」にするのを忘れたときにも、同じエラーが発生します。

持っていた

class ICommProvider { public: /** * @brief If connection is established, it sends the message into the server. * @param[in] msg - message to be send * @return 0 if success, error otherwise */ virtual int vaSend(const std::string &msg) = 0; /** * @brief If connection is established, it is waiting will server response back. * @param[out] msg is the message received from server * @return 0 if success, error otherwise */ virtual int vaReceive(std::string &msg) = 0; virtual int vaSendRaw(const char *buff, int bufflen) = 0; virtual int vaReceiveRaw(char *buff, int bufflen) = 0; /** * @bief Closes current connection (if needed) after serving * @return 0 if success, error otherwise */ virtual int vaClose(); };

最後のvaCloseは仮想ではないので、コンパイルされた場所はどこに実装するかわからず、混乱しました。私のメッセージは：

... TCPClient.o :(。rodata + 0x38）： `typeinfo for ICommProvider 'への未定義の参照

からの簡単な変更

virtual int vaClose();

に

virtual int vaClose() = 0;

問題を修正しました。それが役に立てば幸い

まれな状況に遭遇しましたが、これは同様の状況にある他の友人を助けるかもしれません。古いシステムでgcc 4.4.7を使用する必要があります。c ++ 11以上のサポートでコードをコンパイルする必要があるため、gcc 5.3.0の最新バージョンをビルドします。コードをビルドし、依存関係が古いコンパイラでビルドされている場合に依存関係にリンクすると、リンクパスを-L / path / to / lib -llibnameで明確に定義したにもかかわらず、「undefined reference to」エラーが発生しました。cmakeでビルドされたboostやプロジェクトなどの一部のパッケージは、通常、古いコンパイラーを使用する傾向があり、通常はそのような問題を引き起こします。彼らが新しいコンパイラを使用するようにするためには、長い道のりが必要です。

私の場合、たとえdynamic_cast呼び出しがあっても、それは純粋にライブラリ依存関係の問題です。makefileに十分な依存関係を追加した後、この問題はなくなりました。

依存関係がなしでコンパイルされていることを確認してください-f-nortti。

一部のプロジェクトでは、RocksDBのように、明示的に設定する必要があります。

USE_RTTI=1 make shared_lib -j4

私の場合、それは純粋な仮想として定義されていないインターフェイスクラスの仮想関数でした。

class IInterface
{
public:
  virtual void Foo() = 0;
}

ちょっと忘れました= 0。