RTTI Madness

Hi,
Lately LLVM has been adding -fno-rtti to most of the compiler. I have a pass which uses LoopPass and which inherits from FunctionPass and a class of my own. If I compile my code with ENABLE_RTTI=1, I can't dynamically load the shared object since it won't be able to find the symbol for LoopPass's typeinfo.

undefined symbol: _ZTIN4llvm8LoopPassE
$ c++filt _ZTIN4llvm8LoopPassE
typeinfo for llvm::LoopPass

Alternatively, if I compile with ENABLE_RTTI=1 then the virtual table for my FunctionPass will be messed up. FunctionPass comes from Pass.cpp in ./lib/VMCore which is built with ENABLE_RTTI=1. The difference in the size of the virtual tables between LLVM's code, which is built with RTTI, and my code, which is built without causes the offsets into my derived class's virtual table to be wrong.

What is the recommended course of action?

I don't mind disabling RTTI globally, but I don't understand how RTTI and non-RTTI code can be correctly dynamically linked when there is multiple-inheritance. Unless someone else has a better idea, my preference would be compiling with ENABLE_RTTI=1 globally until the entire compiler is ready to go RTTI-free.

Alternatively, if anyone knows a safe way to dynamically link RTTI and non-RTTI code, I'd appreciate their expertise.

Thanks.
Tom Jablin

This was really irritating to me as well, when I was trying to to eliminate RTTI. The best advice I can give is that it is best to stop using RTTI (and EH) in any of your code if possible. If you want to build LLVM with full rtti support, you can add a REQUIRES_RTTI=1 setting to the top level Makefile.config or on the make command line.

-Chris

On a related note, building googletest with gcc-4.4 doesn't require RTTI,
while building it with gcc-4.2 does require RTTI (due to tr1/functional
using typeid).
I'd be happy if there was a solution for that.

Best regards,
--Edwin

LLVM now builds tests with -DGTEST_HAS_RTTI=0 -DGTEST_HAS_TR1_TUPLE=0
to avoid this problem. Upgrading to googletest 1.4 would avoid the
need for the second option on early gccs but not the first.