[llvm-dev] undefined reference to typeinfo for CmpInst

[Francis Visoiu Mistrih via llvm-dev]

Hello,

I encountered a similar problem with the following classes: ICmpInst,
GetElementPtrInst and PHINode.

I noticed that there were no anchor functions, and the fact that I was using
RTTI in my project and LLVM disabled it, caused vtables and type infos of those
classes to be emitted in multiple translation units.

Since the LLVM Coding Standards require a `Virtual Method Anchor for Classes in
Headers` (http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers),
I added the missing anchors to those classes (r255538).

Here is a similar patch for the classes that you mentioned:
http://reviews.llvm.org/D17467.

Cheers,


-- 
Francis Visoiu Mistrih
francis at epita.fr
EPITA


On Friday, February 19, 2016 8:24 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:



On Fri, Feb 19, 2016 at 11:09 AM, Frank Winter via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Solved. Recompiling LLVM with "-fno-rtti -fPIC" and building my application with "-fno-rtti" solved the issue.
>


LLVM should already set -fno-rtti by default. I think re-compiling your app with -fno-rtti is what fixed the undefined typeinfo symbol errors.

It looks like you are linking LLVM static libs into a shared library, so you also needed to build LLVM with -fPIC. The documented way of doing this is to pass -DLLVM_ENABLE_PIC=ON to cmake.

As a result of this experiment I conclude that the LLVM library cannot be used in applications that make use of RTTI. I guess that's a bug.

You can enable RTTI by passing -DLLVM_ENABLE_RTTI=ON to cmake. This is documented here:
http://llvm.org/docs/CMake.html#llvm-specific-variables


It sounds like the real bug is "make the build documentation less confusing". Sorry about that. =/

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev