Intermittent link errors on UE 5.2

[sinbad]

I've had to stop using RMC for the moment because of this, but I used it successfully for 2 weeks before I started to suddenly get very intermittent link errors with TArray<unsigned char> whenever I included RealtimeMeshSimple.h.

The exact link errors vary depending on circumstances but they're always with TArray<unsigned char>, here is one example that another user raised in March on Discord:

0>UnrealEditor-RealtimeMeshComponent-Win64-DebugGame.lib(.dll): Error LNK2005 : "public: __cdecl TArray<unsigned char,class TSizedDefaultAllocator<32> >::~TArray<unsigned char,class TSizedDefaultAllocator<32> >(void)" (??1?$TArray@EV?$TSizedDefaultAllocator@$0CA@@@@@QEAA@XZ) already defined in Module.Game.gen.1_of_4.cpp.obj
0>{same}.lib(.dll): Error LNK2005 : "private: void __cdecl TArray<unsigned char,class TSizedDefaultAllocator<32> >::ResizeForCopy(int,int)" (?ResizeForCopy@?$TArray@EV?$TSizedDefaultAllocator@$0CA@@@@@AEAAXHH@Z) already defined in Module.Game.gen.1_of_4.cpp.obj
0>{same}.lib(.dll): Error LNK2005 : "public: class TArray<unsigned char,class TSizedDefaultAllocator<32> > & __cdecl TArray<unsigned char,class TSizedDefaultAllocator<32> >::operator=(class TArray<unsigned char,class TSizedDefaultAllocator<32> > const &)" (??4?$TArray@EV?$TSizedDefaultAllocator@$0CA@@@@@QEAAAEAV0@AEBV0@@Z) already defined in Module.Game.gen.1_of_4.cpp.obj
0>   Creating library C:\{path}\..DebugGame.suppressed.lib and object C:\{path}\..DebugGame.suppressed.exp
0>C:\{path}\UnrealEditor-Game-Win64-DebugGame.dll: Error LNK1169 : one or more multiply defined symbols found

I have received the same "multiply defined symbols" error with ~TArray and TArray::operator=. I have also seen LNK2005 undefined symbol for TArray::Reset(), when I use this.

It started happening for me once I made use of TArray<uint8> in my own code a certain number of times in my own structs. I already used it in other places, but adding a seemingly innoccuous extra struct with a TArray<uint8> started triggering it. The errors would appear and disappear depending on exactly which incremental build was done - making a change to one file would sometimes build fine, but when clean building or changing another file, the link errors would return.

I reproduced this on VS 2019 and VS 2022, because I was getting desperate and tried rolling back from VS 2022, thinking it was a compiler bug. I've used C++ for a long time and never had an intermittent problem like this which wasn't a result of mismatched macros, or mismatched CRT linker errors or something like that.

It's very hard for me to give you a repro case because for 2 weeks I never saw it, then it drove me mad for 2 solid days because it kept appearing and disappearing. If you want to see the process I went through, and all the false solutions I thought I'd found before concluding it was RMC, you can find my Mastodon thread here: https://mastodon.gamedev.place/@sinbad/110860709751601234

I'm sorry I can't give you anything more concrete to go on. I thought that it might be due to FRealtimeMeshDataStreamRawData because it subclasses Tarray, and throws a compiler warning about a non-virtual destructor on the base class, but I tried removing that and it didn't help. The only thing that has consistently gotten rid of the link errors is removing RMC from the project, so that's what I'm doing right now. I might try to roll back to the 4.5 branch or the RMC4_UE5 branch later to see if it's gone there, but right now I just need to write some code without random link errors all the time. ;)

I was working with RMC commit 2343686 at all times, with UE 5.2.1 and installed as source under the Plugins/RealtimeMeshComponent folder of my game project.

[Koderz]

This should be gone completely at this point as that way of handling some of the data has been replaced.

If you have this or any other issue in the future, feel free to open a new ticket!

[sinbad]

Thanks very much! I saw your post on Discord about this 👍 I will try RMC again soon, I've managed just with my own customised version of PMC in the mean time.