bUseRTTI=True makes an Unreal Project fail to load

Hi all,

I’m having problems with Unreal 4.17.2

I’ve created a C++ Project from the the Vehicle Template.

Lets call my project RUBController

If I add bUseRTTI = true; to RUBController.Build.cs, I can compile the project without any problem, but if I try to load the project, if fails.

If I set bUseRTTI = false; and compile again, the project opens without any problem.

The error when I set bUseRTTI to true is:

LogLinux: Warning: dlopen failed: /path/to/RUBController/Binaries/Linux/libUE4Editor-RUBController.so: undefined symbol: _ZTI13AGameModeBase
LogModuleManager: Warning: ModuleManager: Unable to load module ' /path/to/RUBController/Binaries/Linux/libUE4Editor-RUBController.so' because the file couldn't be loaded by the OS.

If I run "c++filt _ZTI13AGameModeBase" on the Ubuntu shell, the output is: "typeinfo for AGameModeBase"

Any of you went through this same problem?

How did you solve it?

Hi,

I found the solution myself.

I had to change on LinuxToolChain.cs the method GetRTTIFlag to always return -frtti, and then rebuild Unreal Engine again by running:

./GenerateProjectFiles.sh
make

After that, this error disappeared.

1 Like

This is effectively rebuilding the whole engine with RTTI support.

1 Like

What is the proper way to solve this issue?

I’m getting the same error for either AActor or USceneComponent. If I rebuild the whole engine with RTTI support then I don’t expect the plugin to work for anyone else since I can’t expect them to build the engine in a non-standard way.

A recent post [1] state that RTTI cannot be used whole-engine as suggested here anymore. What module structure should I create in order to create a plugin for a third party external dynamic library that uses dynamic_cast and typeid?

In short, your module need to be split into two: one that is subclassing engine classes (it shouldn’t have RTTI enabled because that will require new symbols from the engine) and another that is not (it can have RTTI enabled). You’ll need to keep the interface between them simple (C-like preferably) to avoid pulling in the typeinfo requirements.