Unresolved externals splitting SMaterial.h

[robmar]

Its been a long time since I had a problem I couldn't seem to fix, so thought I'd ask for help!

I use Irrlicht as a normal DLL, driving it from a staticallt linked MFC application, however recently I added functions to SMaterial.h that use new and delete[].

The problem is that calls within Irrlicht use the standard library new and delete, and calls from MFC are using the AFX ones, and the blockuse references are different. I guess they use different heaps or something.

I read that the problem might be having the code in the smaterial.h header rather than a .cpp, as then the code gets compliled by the MFC app too.

So I split SMaterial.h into a matching .cpp and it all compiles nicely, until link time.

Now all the SMaterial functions moved into the CPP including destructor, are listing as unresolved.

Any ideas to fix this would be much appreciated. Thanks

[CuteAlien]

Did you set _IRR_STATIC_LIB_ in both projects (Irrlicht and your own project). It's probably set already in Irrlicht when you compile with target "static", but you have to set that define in your own project as well.

[robmar]

Hi, thanks for the reply. Everything linked perfectly in my MFC app until I added SMaterial.cpp to Irrlich, and moved some of the functions defined in SMaterial.h to it's new .cpp.

Absolutely everything compiles correctly, but I get unresolved externals at link time of my MFC app.

There isn´t a link .def file, and __cdeclspec isn't used, so not sure where classes are listed for external linking in Irrlicht.

Sure I've forgotten something sooo obvious!

[CuteAlien]

Post your .cpp and .h files somewhere. And exact link errors. Can't help otherwise. But nearly every time I get link errors related to SMaterial it's because I forgot to set _IRR_STATIC_LIB_ in my project.

[robmar]

Sorry, I got that backwards, I'm using Irrlicht as a standard dll, with a statically linked MFC application.

My problem started when I added two variables to SMaterial, to hold the texture filename and bump filename, set during mesh loading.
To reduce memory, I added to simple array pointers: c8* pTexFilename.
I then used "new c8[iLen]" to allocate in the loader, and delete[] before reloading, however the call to the new SMaterial proc to Copy (using the same delete[], resulted in an memory handler exception.

The problem was that when Irrlicht called the procedure, not being MFC-based, it used the standard libray "new", whereas calling from my application, it used the AFX delete, and bang!

Someone mentioned on StackExchange that as the code was in the header, it was compiled differently by both app and dll, hence the issue.

So I moved the function into a new SMaterial.cpp, but of course there are not exports for SMaterial.

I could add a function in the driver to do the SMaterial copy, but is there a better way?

[CuteAlien]

Please show me the current code. You might have to use the irrAllocator (it was created because of that kind of problem).

[robmar]

Thanks for the tip! I just saw that irrAllocator is to handle memory allocation "across all dll boundaries", so that would be what was needed!
Good for future ref!

Anyway, I added new functions to IVideoDriver and the rest, such as newMaterial(), deleteMaterial(), CopyStringtoMaterial()-which uses memcpy.
Called from the MFC app, they call the same new and delete[] functions as I had in my MFC app (... new SMaterial) but now call the standard memory allocators, not the AFX ones MFC uses.

Looking at IrrAllocator I see it does exactly the same but in a generic manner:

Code: Select all

00033     T* allocate(size_t cnt)
00034     {
00035         return (T*)internal_new(cnt* sizeof(T));
00036     }
 
00058     virtual void* internal_new(size_t cnt)
00059     {
00060         return operator new(cnt);
00061     }

Seems as efficient as possible, though could be marked "inline", though optimization will probably do that anyway.

Amazing how much time can be lost by not knowing or remembering a tiny detail!