Weird 64-bit errors?

Hi Guys,

I decided to try and dust off some old projects over the weekend and I’m receiving some errors that I don’t recall how to solve. I looked up a few about the non-virtual thunk errors and it leads me to believe that I need to implement some functions that are declared in .h but not then implemented in .cpp.

Does anyone have thoughts?

Hi @drelaptop Do you know why? Happens in 3.17 and 3.16 for me. I can try a few versions back to see also.

It seems like you do not link cocos2d-x library or you link incorrect version.
Consider to create new project and than copy yours cpp files.

Thanks. I’ll try that after I get more work done for the day :-). I’m trying to update the physics docs

I think the 64-bit arch isn’t one of default building archs. if you want to build 64-bit arch, you should set the arch for all the related project. including all libs build target.

In other word, if you build TempleteCpp target using 64-bit, but libcocos2d target using 32-bit target, you will get those errors.

So I am running cocos gen-libs and it is producing 64-bit static libs

I’ll look at XCode project settings next.

So this is happening in every single project I have.

I’ve had this issue a few times. I’m trying to remember the fix (unfortunately it was quite a process to figure out and thus too many paths to remember the success). I’ll search my notes on the off chance I wrote it down.

Off top of my head …

  • Prebuilts used to not support 64-bit on iOS previously, possibly still? Like zlib, truetype, box2d, etc.
  • Possibly cached build artifacts (my goto early check is fully cleaned project/libs)
  • Mismatched architecture build setting between cocos2d and game projects (possibly others as well)
  • If recently upgraded XCode, might be no longer valid Xcode/iOS SDK frameworks (OpenGL.framework, et al), try removing from build libraries and add back in (which will link against latest version)

The vtable issue what I saw occur for me as well.

If you want to confirm I think that if you find the build intermediates there will be all the *.o files that you can run name CCSprite.o for example and if you grep the listing for one of the issues (e.g. getPositionNormalized()) you might not find it listed (and thus there was an issue building it for that target/arch.

Anyway, hope that maybe helps in some manner to find issue.

It’s also possible that something stupid/simple fixed it like a full clean+rebuild, or forgetting to run download-deps.py, etc …???

@stevetranby Thanks. I’ll see what I can come up with. cocos new works. projects that I use the prebuilts with do not work.