After enabling a section of code with many virtual functions I am getting ARM linker error L6647:

The virtual function elimination information for <vcall_objectname>(<vcall_sectionname>) incorrectly indicates that section <curr_sectionname>(object <curr_objectname>), offset <offset> is a relocation (to a virtual function or RTTI), but there is no relocation at that offset.

This site says it is likely a tool bug:

L6647E
The virtual function elimination information for <vcall_objectname>(<vcall_sectionname>) incorrectly indicates that section <curr_sectionname>(object <curr_objectname>), offset <offset> is a relocation (to a virtual function or RTTI), but there is no relocation at that offset.
This message might indicate a compiler fault. Contact your supplier.

Has anyone ever encountered this anywhere ever before?

Are there are known work-arounds? If I remove the virtual function causing the error for testing purposes it just moves on to the next virtual function and I am unable to proceed at all.

L. Spiro

Is it a pure virtual function thing? Have you tried giving them an (empty) implementation? You can do

virtual void foo() = 0 {}

to provide an empty implementation which may help? Just kicking around a football inflated with ideas here.

The base class is not pure virtual and has a default implementation.
There seems to be nothing remarkable about this function, and indeed removing this function moves the error onto the next unremarkable virtual function.

For what it is worth, this is for Nintendo 3DS which has strange packing rules for class inheritance.

My immediate wild-ass-guess would be that your class is entirely defined in a header file, and thus is being inlined and no vtable generated in the first place.

If so, place function definitions for at least one virtual function (i.e. the destructor) in the matching .cpp file.

The function(s) causing this error are defined in the .CPP.

But actually I might try the reverse and put it into the header just to see what happens (although virtual functions can never be inlined).

Keep the ideas coming. I am willing to try almost anything. It is obviously a crazy bug so a crazy solution will likely be necessary.

L. Spiro

I tried --keep=*. Very long linker time, but the problem remains.

Optimizations are off.

Can’t…

…succeed…

…Slowly…

…dying…

L. Spiro…

More stabs in the dark:

* Disable RTTI

* Clean rebuild

* Disable incremental linking

* Try isolating the offending code and compiling and linking it in a newer/different compiler (I secretly hope this will be indeed a compiler/linker bug that will force you to finally upgrade to a newer version than VS2005).

(although virtual functions can never be inlined)

<offtopic>

Tell that to GCC. I've been bitten by this several times lately - it seems that if you create a class entirely in the header file (without pure virtual functions), all the virtual functions get inlined in each translation unit, causing no vtable to be emitted, and then linker hell ensues...

</offtopic>