Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


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: 14197

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

Sponsor:

#2 Paradigm Shifter   Crossbones+   -  Reputation: 5432

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: 10360

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: 14197

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 frob   Moderators   -  Reputation: 22692

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 write about assorted stuff.


#6 L. Spiro   Crossbones+   -  Reputation: 14197

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…


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#7 Amr0   Members   -  Reputation: 1152

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: 10360

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: 22692

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