blocks|key|359584|text|一个可能的原因是您在没有定义的情况下声明了一个虚函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359585|如果您在没有在同一编译单元中定义它的情况下声明它，则表示它是在其他地方定义的-这意味着链接器阶段将尝试在其他编译单元(或库)中查找它。|359586|定义虚拟函数的一个示例是：|359587|virtual+void+fn()+{+/*+insert+code+here+*/+}|code-block|syntax|javascript|359588|在本例中，您将一个定义附加到声明，这意味着链接器不需要在以后解析它。|359589|这条线|359590|virtual+void+fn();|359591|在未定义的情况下声明fn()，并将导致您询问的错误消息。|offset|length|style|CODE|359592|它与代码非常相似：|359593|extern+int+i;
int+*pi+=+&i;|359594|这说明整数i是在另一个编译单元中声明的，该单元必须在链接时解析(否则pi不能设置为它的地址)。|359595|entityMap^0|0|0|0|0|0|0|0|A|4|0|0|0|5|1|Y|2|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|1A|8|@]|9|@]|A|$I|J]]|$1|Q|3|R|5|6|7|1B|8|@$S|1C|T|1D|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|1F|8|@]|9|@]|A|$I|J]]|$1|10|3|11|5|6|7|1G|8|@$S|1H|T|1I|U|V]|$S|1J|T|1K|U|V]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|13|$]]

One possible reason is because you are declaring a virtual function without defining it.

When you declare it without defining it in the same compilation unit, you're indicating that it's defined somewhere else - this means the linker phase will try to find it in one of the other compilation units (or libraries).

An example of defining the virtual function is:

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

In this case, you are attaching a definition to the declaration, which means the linker doesn't need to resolve it later.

The line

<pre><code>virtual void fn();
</code></pre>

declares <code>fn()</code> without defining it and will cause the error message you asked about.

It's very similar to the code:

<pre><code>extern int i;
int *pi = &amp;i;
</code></pre>

which states that the integer <code>i</code> is declared in another compilation unit which must be resolved at link time (otherwise <code>pi</code> can't be set to it's address).

blocks|key|354952|text|当您混合使用-fno-rtti和-frtti代码时，也会发生这种情况。然后，您需要确保任何在-frtti代码中访问的type_info类都使用-frtti编译了它们的关键方法。当你创建一个类的对象，使用dynamic_cast等，就会发生这样的访问。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|354953|[source]|354954|entityMap|0|LINK|mutability|MUTABLE|url|http://web.archive.org/web/20100503172629/http://www.pubbs.net/201004/gcc/25970-linker-error-undefined-reference-to-typeinfo-for-a-with-no-rtti-option.html^0|6|9|G|6|1A|6|1M|9|1Z|6|2T|C|0|1|6|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@]|D|@$9|13|A|14|1|15]]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

This can also happen when you mix <code>-fno-rtti</code> and <code>-frtti</code> code. Then you need to ensure that any class, which <code>type_info</code> is accessed in the <code>-frtti</code> code, have their key method compiled with <code>-frtti</code>. Such access can happen when you create an object of the class, use <code>dynamic_cast</code> etc.

[<a href="http://web.archive.org/web/20100503172629/http://www.pubbs.net/201004/gcc/25970-linker-error-undefined-reference-to-typeinfo-for-a-with-no-rtti-option.html" rel="noreferrer">source</a>]

blocks|key|3141492|text|当声明的(非纯)虚函数缺少主体时，就会发生这种情况。在您的类定义中，类似于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141493|virtual+void+foo();|code-block|syntax|javascript|3141494|应定义(内联或在链接的源文件中)：|3141495|virtual+void+foo()+{}|3141496|或者声明为纯虚拟的：|3141497|virtual+void+foo()+=+0;|3141498|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

This occurs when declared (non-pure) virtual functions are missing bodies. In your class definition, something like:

<pre><code>virtual void foo();
</code></pre>

Should be defined (inline or in a linked source file):

<pre><code>virtual void foo() {}
</code></pre>

Or declared pure virtual:

<pre><code>virtual void foo() = 0;
</code></pre>

blocks|key|354908|text|引用the+gcc+manual|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|354909|对于多态类(具有虚函数的类)，type_info对象与vtable一起写出...对于所有其他类型，我们在使用时写出type_info对象:将‘`typeid’应用于表达式时，抛出对象，或在catch子句或异常规范中引用类型时。|354910|354911|在同一页上的更早一点：|354912|354913|如果类声明了任何非内联、非纯虚函数，则选择第一个函数作为该类的“键方法”，并且只在定义键方法的转换单元中发出vtable。|blockquote|354914|354915|354916|因此，当"key+method“缺少它的定义时，就会出现这个错误，正如前面提到的其他答案。|354917|entityMap|0|LINK|mutability|MUTABLE|url|http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html^0|2|E|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|J|3|K|5|L|7|16|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

Quoting from <a href="http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html" rel="noreferrer">the gcc manual</a>:

<blockquote>
 For polymorphic classes (classes with virtual functions), the type_info object is written out along with the vtable [...] For all other types, we write out the type_info object when it is used: when applying `typeid' to an expression, throwing an object, or referring to a type in a catch clause or exception specification.
</blockquote>

And a bit earlier on the same page:

<blockquote>
 If the class declares any non-inline, non-pure virtual functions, the first one is chosen as the “key method” for the class, and the vtable is only emitted in the translation unit where the key method is defined.
</blockquote>

So, this error happens when the "key method" is missing its definition, as other answers already mentioned.

blocks|key|3354642|text|如果您将一个.so链接到另一个，还有一种可能性是在gcc或g%2B%2B中使用"-fvisibility=hidden“进行编译。如果两个.so文件都是用"-fvisibility=hidden“构建的，并且键方法与另一个虚拟函数的实现不在同一个.so中，则后者不会看到前者的vtable或typeinfo。对于链接器来说，这看起来像是一个未实现的虚函数(就像paxdiablo和cdleary的答案一样)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3354643|在这种情况下，必须为基类的可见性使用|3354644|__attribute__+((visibility("default")))|code-block|syntax|javascript|3354645|在类声明中。例如,|3354646|class+__attribute__+((visibility("default")))+boom{
++++virtual+void+stick();
}|3354647|当然，另一种解决方案是不使用“-fvisibility=hidden”。这会使编译器和链接器的事情变得复杂，可能会损害代码性能。|3354648|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

If you're linking one .so to another, yet one more possibility is compiling with "-fvisibility=hidden" in gcc or g++. If both .so files were built with "-fvisibility=hidden" and the key method is not in the same .so as another of the virtual function's implementations, the latter won't see the vtable or typeinfo of the former. To the linker, this looks like an unimplemented virtual function (as in paxdiablo's and cdleary's answers).

In this case, you must make an exception for the visibility of the base class with 

<pre><code>__attribute__ ((visibility("default")))
</code></pre>

in the class declaration. For instance,

<pre><code>class __attribute__ ((visibility("default"))) boom{
 virtual void stick();
}
</code></pre>

Another solution, of course, is to not use "-fvisibility=hidden." That does complicate things for the compiler and linker, possibly to the detriment of code performance.

blocks|key|356296|text|前面的答案是正确的，但此错误也可能是由于试图在没有虚函数的类的对象上使用typeid而导致的。C%2B%2B+RTTI需要一个vtable，因此您希望对其执行类型识别的类至少需要一个虚拟函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356297|如果你想让类型信息在你不想要任何虚函数的类上工作，那就把析构函数设为虚函数。|356298|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The previous answers are correct, but this error can also be caused by attempting to use typeid on an object of a class that has no virtual functions. C++ RTTI requires a vtable, so classes that you wish to perform type identification on require at least one virtual function. 

If you want type information to work on a class for which you don't really want any virtual functions, make the destructor virtual.

blocks|key|3141845|text|我只是在这个错误上花了几个小时，虽然这里的其他答案帮助我理解了发生了什么，但它们并没有解决我特定的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141846|我正在做一个同时使用clang%2B%2B和g%2B%2B编译的项目。我使用clang%2B%2B时没有链接问题，但使用g%2B%2B时出现了undefined+reference+to+'typeinfo+for错误。|offset|length|style|CODE|3141847|要点：链接顺序与g%2B%2B密切相关。如果您按不正确的顺序列出了您想要链接的库，您可能会得到typeinfo错误。|BOLD|3141848|有关与gcc/g%2B%2B的链接顺序的更多详细信息，请参阅this+SO+question。|3141849|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc^0|0|A|7|I|3|U|7|1C|3|1J|10|0|0|3|8|3|17|8|0|3|3|7|3|Q|G|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@$D|W|E|X|F|G]|$D|Y|E|Z|F|G]|$D|10|E|11|F|G]|$D|12|E|13|F|G]|$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@$D|17|E|18|F|J]|$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|K|3|L|5|6|7|1D|8|@$D|1E|E|1F|F|G]|$D|1G|E|1H|F|G]]|9|@$D|1I|E|1J|1|1K]]|A|$]]|$1|M|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

I just spent a few hours on this error, and while the other answers here helped me understand what was going on, they did not fix my particular problem. 

I am working on a project that compiles using both <code>clang++</code> and <code>g++</code>. I was having no linking issues using <code>clang++</code>, but was getting the <code>undefined reference to 'typeinfo for</code> error with <code>g++</code>.

The important point: Linking order MATTERS with <code>g++</code>. If you list the libraries you want to link in an order which is incorrect you can get the <code>typeinfo</code> error.

See <a href="https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc">this SO question</a> for more details on linking order with <code>gcc</code>/<code>g++</code>.

blocks|key|357129|text|处理RTTI和非RTTI库的代码的可能解决方案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357130|a)使用-frtti或-fno-rtti重新编译所有内容|357131|b)如果a)对您来说不可能，请尝试以下方法：|357132|假设libfoo是在没有RTTI的情况下构建的。您的代码使用libfoo并使用RTTI进行编译。如果在libfoo中使用具有虚拟的类(+Foo+)，很可能会遇到链接时错误:缺少类Foo的typeinfo。|357133|定义另一个没有虚拟的类(例如FooAdapter)，它会将调用转发到您使用的Foo。|357134|在一个不使用FooAdapter并且只依赖于libfoo符号的小静态库中编译libfoo。为它提供一个头，并在你的代码中使用它(它使用RTTI)。由于FooAdapter没有虚函数，所以它不会有任何类型信息，您将能够链接您的二进制文件。如果您在libfoo中使用了大量不同的类，那么这个解决方案可能不太方便，但这是一个开始。|357135|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Possible solutions for code that deal with RTTI and non-RTTI libraries:

a) Recompile everything with either -frtti or -fno-rtti 
b) If a) is not possible for you, try the following:

Assume libfoo is built without RTTI. Your code uses libfoo and compiles with RTTI. If you use a class (Foo) in libfoo that has virtuals, you're likely to run into a link-time error that says: missing typeinfo for class Foo.

Define another class (e.g. FooAdapter) that has no virtual and will forward calls to Foo that you use.

Compile FooAdapter in a small static library that doesn't use RTTI and only depends on libfoo symbols. Provide a header for it and use that instead in your code (which uses RTTI). Since FooAdapter has no virtual function it won't have any typeinfo and you'll be able to link your binary. If you use a lot of different classes from libfoo, this solution may not be convenient, but it's a start.

blocks|key|3354736|text|在基类(抽象基类)中，您声明了一个虚拟析构函数，并且由于您不能将一个析构函数声明为一个纯虚函数，因此您要么必须在抽象类中定义它，只需像virtual+~+base+()+{}这样的虚拟定义，要么在任何派生类中定义它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3354737|如果你做不到这一点，你将在链接时以一个“未定义的符号”结束。因为VMT对所有具有匹配NULL的纯虚函数都有一个条目，因为它根据派生类中的实现来更新表。但对于非纯虚函数，它需要在链接时定义，以便更新VMT表。|3354738|使用c%2B%2Bfilt取消符号的边框。与$c%2B%2Bfilt类似，_ZTIN10storageapi8BaseHostE将输出类似于"typeinfo+for+storageapi::BaseHost“的内容。|3354739|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

In the base class (an abstract base class) you declare a virtual destructor and as you cannot declare a destructor as a pure virtual function, either you have to define it right here in the abstract class, just a dummy definition like virtual ~base() { } will do, or in any of the derived class.

If you fail to do this, you will end up in an "undefined symbol" at link time.
Since VMT has an entry for all the pure virtual functions with a matching NULL as it updates the table depending on the implementation in the derived class. But for the non-pure but virtual functions, it needs the definition at the link time so that it can update the VMT table.

Use c++filt to demangle the symbol. Like $c++filt _ZTIN10storageapi8BaseHostE
will output something like "typeinfo for storageapi::BaseHost".

blocks|key|3354791|text|类似于上面的RTTI，NO-RTTI讨论，如果你使用dynamic_cast并且没有包含包含类实现的目标代码，也会发生这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3354792|我在Cygwin上构建，然后将代码移植到Linux上时遇到了这个问题。在这两种情况下，make文件、目录结构甚至是gcc版本(4.8.2)都是相同的，但代码在Cygwin上链接和操作正确，但在Linux上无法链接。Red+Hat+Cygwin显然已经对编译器/链接器进行了修改，以避免目标代码链接的要求。|3354793|Linux链接器错误消息正确地将我引向了dynamic_cast行，但这个论坛上的早期消息让我寻找的是缺少的函数实现，而不是实际的问题:缺少目标代码。我的解决方法是在基类和派生类中替换虚拟类型函数，例如虚拟int+isSpecialType()，而不是使用dynamic_cast。这种技术避免了仅仅为了让dynamic_cast正常工作而链接对象实现代码的要求。|3354794|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Similarly to the RTTI, NO-RTTI discussion above, this problem can also occur if you use dynamic_cast and fail to include the object code containing the class implementation.

I ran into this problem building on Cygwin and then porting code to Linux. The make files, directory structure and even the gcc versions (4.8.2) were identical in both cases, but the code linked and operated correctly on Cygwin but failed to link on Linux. Red Hat Cygwin has apparently made compiler/linker modifications that avoid the object code linking requirement.

The Linux linker error message properly directed me to the dynamic_cast line, but earlier messages in this forum had me looking for missing function implementations rather than the actual problem: missing object code. My workaround was to substitute a virtual type function in the base and derived class, e.g. virtual int isSpecialType(), rather than use dynamic_cast. This technique avoids the requirement to link object implementation code just to get dynamic_cast to work properly.

blocks|key|3354824|text|我刚刚收到了很多这样的错误。发生的情况是，我将一个仅包含头文件的类拆分为一个头文件和一个cpp文件。但是，我没有更新我的构建系统，所以cpp文件没有被编译。在对头文件中声明但未实现的函数的引用未定义的情况下，我收到了很多这样的typeinfo错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3354825|解决方案是重新运行构建系统以编译和链接新的cpp文件。|3354826|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I got a lot of these errors just now. What happened is that I split a header-file-only class into a header file and a cpp file. However, I didn't update my build system, so the cpp file didn't get compiled. Among simply having undefined references to the functions declared in the header but not implemented, I got a lot of these typeinfo errors. 

The solution was to re-run the build system to compile and link the new cpp file.

blocks|key|3141981|text|在我的例子中，我使用了一个带有头文件和so文件的第三方库。我创建了一个子类，当我试图实例化我的子类时，出现了类似这样的链接错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141982|正如@sergiy提到的，知道这可能是'rtti‘的问题，我设法解决了这个问题，通过将构造函数的实现放在单独的.cpp文件中，并将'-fno-rtti’编译标志应用到文件中。它工作得很好。|offset|length|style|BOLD|3141983|由于我仍然不太清楚这个链接错误的内部原因，我不确定我的解决方案是否通用。然而，我认为在尝试@francois提到的适配器方法之前，值得一试。当然，如果所有源代码都可用(在我的例子中不是)，如果可能的话，最好用'-frtti‘重新编译。|3141984|还有一件事，如果您选择尝试我的解决方案，请尝试使单独的文件尽可能简单，并且不要使用C%2B%2B的一些花哨的功能。特别关注boost相关的东西，因为它很大程度上依赖于rtti。|3141985|entityMap^0|0|16|17|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

in my case, i used a third-party library with header files and so file. i subclassed one class, and link error like this occurred when i try to instantiate my subclass.

as mentioned by @sergiy, knowning it could be the problem of 'rtti', i managed to workaround it by put the constructor implementation into separate .cpp file and apply '-fno-rtti' compile flags to the file. it works well.

as i am still not quite clear about the internal of this link error, i am not sure whether my solution is general. however, i think it worth a shot before trying the adaptor way as mentioned by @francois . and of course, if all source codes are available(not in my case), better do recompile with '-frtti' if possible.

one more thing, if you choose to try my solution, try make the separate file as simple as possible, and do not use some fancy features of C++. take special attention on boost related things, cause much of it depends on rtti.

blocks|key|357246|text|在我的例子中，它是接口类中的一个虚函数，没有定义为纯虚函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357247|class+IInterface
{
public:
++virtual+void+Foo()+=+0;
}|code-block|syntax|javascript|357248|我忘了=+0部分。|offset|length|style|BOLD|CODE|357249|entityMap^0|0|0|3|3|3|3|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|R|8|@$I|S|J|T|K|L]|$I|U|J|V|K|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

In my case it was a virtual function in an interface class that wasn't defined as a pure virtual.

<pre><code>class IInterface
{
public:
 virtual void Foo() = 0;
}
</code></pre>

I forgot the <code>= 0</code> bit.

blocks|key|357226|text|当我的接口(具有所有的纯虚函数)需要多一个函数，而我忘记将其"null“时，我也得到了同样的错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357227|我有|357228|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();+};|offset|length|style|CODE|357229|最后，vaClose不是虚拟的，所以编译后不知道从哪里获取它的实现，因此感到困惑。我的信息是：|357230|357231|+...TCPClient.o:(.rodata%2B0x38)：对`ICommProvider的`typeinfo‘的引用未定义|blockquote|357232|357233|357234|简单更改，从|357235|virtual+int+vaClose();|code-block|syntax|javascript|357236|至|357237|virtual+int+vaClose()+=+0;|357238|已修复此问题。希望能有所帮助|357239|entityMap^0|0|0|0|MD|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@$F|19|G|1A|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|1D|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1G|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1H|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1I|8|@]|9|@]|A|$]]|$1|10|3|11|5|V|7|1J|8|@]|9|@]|A|$W|X]]|$1|12|3|13|5|6|7|1K|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|15|$]]

I've got same error when my interface (with all pure virtual functions) needed one more function and I forgot to "null" it.

I had

<code>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 &amp;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 &amp;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();
};</code>

Last vaClose is not virtual so compiled did not know where to get implementation for it and thereby got confused. my message was:

<blockquote>
 ...TCPClient.o:(.rodata+0x38): undefined reference to `typeinfo for ICommProvider'
</blockquote>

Simple change from

<pre><code>virtual int vaClose();
</code></pre>

to

<pre><code>virtual int vaClose() = 0;
</code></pre>

fixed the problem. hope it helps

blocks|key|359775|text|我遇到了一种罕见的情况，但这可能会帮助其他类似情况的朋友。我不得不使用较旧的系统，使用的是gcc+4.4.7。我必须编译支持c%2B%2B11或更高版本的代码，所以我构建了最新版本的gcc+5.3.0。当构建我的代码并链接到依赖项时，如果依赖项是使用较旧的编译器构建的，那么即使我用-L/+path+/+to+/lib+-llibname清楚地定义了链接路径，我也会得到“未定义的引用到”错误。一些包，如boost和使用cmake构建的项目，通常倾向于使用较旧的编译器，它们通常会导致此类问题。要确保他们使用较新的编译器，您必须走很长一段路。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359776|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I encounter an situation that is rare, but this may help other friends in similar situation. I have to work on an older system with gcc 4.4.7. I have to compile code with c++11 or above support, so I build the latest version of gcc 5.3.0. When building my code and linking to the dependencies if the dependency is build with older compiler, then I got 'undefined reference to' error even though I clearly defined the linking path with -L/path/to/lib -llibname. Some packages such as boost and projects build with cmake usually has a tendency to use the older compiler, and they usually cause such problems. You have to go a long way to make sure they use the newer compiler.

blocks|key|357243|text|在我的例子中，这纯粹是一个库依赖问题，即使我有dynamic_cast调用。在makefile中添加了足够的依赖项后，这个问题就消失了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357244|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case it is purely a library dependency issue even if I have dynamic_cast call. After adding enough dependency into makefile this problem was gone.

blocks|key|357260|text|通过这个错误消息，G%2B%2B的链接器告诉你，它无法在需要的时候为给定的类组装完整的静态typeinfo描述符。正如许多人已经指出的那样，这很可能是因为缺少虚函数的定义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357261|然而，不好的是，错误消息的顺序可能与直觉相反，“对typeinfo的未定义引用”出现在对缺少的虚拟定义的未定义引用之前。下面是一个我刚刚体验过的例子：|357262|/usr/bin/ld:+module.o:(.data.rel.ro%2B0x10):+undefined+reference+to+`typeinfo+for+type_xxx'
/usr/bin/ld:+module.o:(.data.rel.ro%2B0x28):+undefined+reference+to+`typeinfo+for+type_xxx'
/usr/bin/ld:+module.o:(.data.rel.ro%2B0x40):+undefined+reference+to+`typeinfo+for+type_xxx'
/usr/bin/ld:+module.o:(.data.rel.ro%2B0x150):+undefined+reference+to+`type_xxx::has_property(std::__cxx11::basic_string<char,+std::char_traits<char>,+std::allocator<char>+>+const&)'|code-block|syntax|javascript|357263|因此，缺少type_xxx::has_property(const+std::string&)定义只会报告为第四个错误。所以，有时跳过那些人们不理解的错误消息，并首先处理那些容易理解的错误消息是值得的。因为在这种情况下，添加缺失的定义也会修复未定义的typeinfo引用的问题。|offset|length|style|CODE|357264|entityMap^0|0|0|0|5|16|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@$K|U|L|V|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

With this error message, G++'s linker is telling you, that it cannot assemble the full static typeinfo descriptor for a given class, when it is needed. As many have already pointed out, this is most likely due to missing definitions of virtual functions.
The bad thing, though, is, that the order of error messages may be counter-intuitive, with the &quot;undefined reference to typeinfo&quot; occuring before the undefined references to the missing virtual definitions. Here an example, that I just experienced:
<pre><code>/usr/bin/ld: module.o:(.data.rel.ro+0x10): undefined reference to `typeinfo for type_xxx'
/usr/bin/ld: module.o:(.data.rel.ro+0x28): undefined reference to `typeinfo for type_xxx'
/usr/bin/ld: module.o:(.data.rel.ro+0x40): undefined reference to `typeinfo for type_xxx'
/usr/bin/ld: module.o:(.data.rel.ro+0x150): undefined reference to `type_xxx::has_property(std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt; const&amp;)'
</code></pre>
So that missing definition of <code>type_xxx::has_property(const std::string&amp;)</code> is only reported as the fourth error. So, sometimes it pays off to skip those error messages, that one doesn't understand, and handle the ones, first, that are easy to understand. Because in this case, adding the missing definitions then also fixes the problem with the undefined typeinfo references.

blocks|key|3355004|text|检查您的依赖项是否在没有使用-f-nortti的情况下编译。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3355005|对于某些项目，您必须显式设置它，例如在RocksDB中：|3355006|USE_RTTI=1+make+shared_lib+-j4|code-block|syntax|javascript|3355007|entityMap^0|E|9|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|R|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|S|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

Check that your dependencies were compiled without <code>-f-nortti</code>.

For some projects you have to set it explicitly, like in RocksDB:

<pre><code>USE_RTTI=1 make shared_lib -j4
</code></pre>

I just ran across the following error (and found the solution online, but it's not present in Stack Overflow):

<blockquote>
 (.gnu.linkonce.[stuff]): undefined
 reference to [method] [object
 file]:(.gnu.linkonce.[stuff]):
 undefined reference to `typeinfo for
 [classname]'
</blockquote>

Why might one get one of these "undefined reference to typeinfo" linker errors?

(Bonus points if you can explain what's going on behind the scenes.)

g++ undefined reference to typeinfo

编译器

Linux

我刚刚遇到了以下错误(我在网上找到了解决方案，但它不存在于Stack Overflow中)： (.gnu.linkonce.stuff)：未定义对方法的引用：(.gnu.linkonce.stuff)：未定义对` `typeinfo for classname‘的引用为什么会出现这样的“对typeinfo的引用未定义”的链接器错误？(如果你能解释幕后发生的事情，你会得到加分。)

问g++对typeinfo的引用未定义
EN

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问g++对typeinfo的引用未定义EN

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问g++对typeinfo的引用未定义
EN