Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Linker Error L6647


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 L. Spiro   Crossbones+   -  Reputation: 21356

Like
0Likes
Like

Posted 21 February 2013 - 09:28 PM

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



Sponsor:

#2 Paradigm Shifter   Crossbones+   -  Reputation: 5674

Like
1Likes
Like

Posted 21 February 2013 - 09:42 PM

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.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#3 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
2Likes
Like

Posted 21 February 2013 - 09:48 PM

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.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#4 L. Spiro   Crossbones+   -  Reputation: 21356

Like
0Likes
Like

Posted 21 February 2013 - 09:53 PM

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



#5 frob   Moderators   -  Reputation: 31376

Like
1Likes
Like

Posted 21 February 2013 - 10:35 PM

I've seen similar issues where the compiler optimized-out virtual functions because it couldn't find references to the function.

Try the -keep linker option.

Also try setting the optimization options to be less aggressive.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.


#6 L. Spiro   Crossbones+   -  Reputation: 21356

Like
0Likes
Like

Posted 21 February 2013 - 11:46 PM

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

Optimizations are off.

 

Can’t…

…succeed…

…Slowly…

 

…dying…

 

 

L. Spiro…



#7 Amr0   Members   -  Reputation: 1434

Like
1Likes
Like

Posted 22 February 2013 - 02:28 AM

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).



#8 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
0Likes
Like

Posted 22 February 2013 - 08:46 AM

(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>


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#9 frob   Moderators   -  Reputation: 31376

Like
1Likes
Like

Posted 22 February 2013 - 08:57 AM

Worst case workaround:

Implement a pointer to a jump table that you implement in each class. Name it 'vtable'.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS