Irrlicht DLL crashing -- binary incompatibility?

[Greatwolf]

Hi everyone,

I'm trying to use the precompiled dll's that comes with the irrlicht SDK, either the msvc dll or gcc dll and trying to get it to work under borland's 5.5 free compiler. I'm trying to see if dll interoperability is possible when mixing different development tools. This isn't just for borland -- in the future I might want to get a mingw dll to work with digital mars compiler or msvc compiler or visa versa.

I've considered building irrlicht from source but the borland compiler gives too many warnings and errors. I don't have the time or inclination to hack the source trying to get it to build under borland. On the other hand, if I can get precompiled dll's to work then it could save a lot of time and effort since this could be done for other open source projects and tools etc.

So I googled and did some research online regarding what I'm trying to do. I found these two links particularly helpful for what I'm trying to achieve:

http://chadaustin.me/cppinterface.html
http://www.codeproject.com/KB/cpp/howto ... id=2929651

From checking out the irrlicht header files, it looks like irrlicht uses a similar design layout at the top level. Everything looks good so far, calling host programs should be able to interface with irrlicht by taking advantage of the vtable layout.

I created an import library from the supplied irrlicht.dll binary, ensured the exported naming decorations are workable for my target compiler. I proceed to compile the 01.Hello World demo.

The CreateDevice() function returns an IrrlichtDevice object back to hello world demo. At this point, if I try to call a method on this irrlichtdevice* it results in an exception thrown.

Code: Select all

/* Hello world.cpp 
 * using irrlicht.dll compiled with mingw gcc compiler
 */

//this line runs ok on both bcc and mingw
//pointer appears valid from stepping through debugger
IrrlichtDevice* device = createDevice( video::EDT_SOFTWARE,
                                                dimension2d<u32>(640, 480), 16,
                                                false, false, false, 0);

//this following line crashes with an exception thrown
//when built with bcc -- but doesn't crash for mingw
//even for a simple function call that returns bool and takes no arguments
device->isFullscreen();

I worked on this problem for a few days trying to figure out as much as I can. I'm not sure why this is happening -- what is happening across the dll boundary that could cause it to crash?

In an attempt to fix this, I moved all the object method invocation into the dll instead as a wrapper. The wrapper merely maps the object methods to the corresponding device object method. That seems to work much better. I step through the program execution and most of the object calls seem to go through fine -- getVideoDriver, getSceneManager, getGUIEnvironment all work, external model files load ok etc. But when it comes time to actually draw the scene, that's when it throws an exception again.

Code: Select all

//main loop of the hello world.cpp demo
while(device->run())
{
  driver->beginScene(true, true, SColor(255,100,101,140));

//this following line throws an exception in bcc!
   smgr->drawAll();

  guienv->drawAll();

  driver->endScene();
}

Here's what I have observed from the scene manage:

• -if smgr->drawAll() is commented out, then no exception is thrown.
  -if no camerascenenode is added to smgr then no exception is thrown.
  -or if no mesh is added to smgr, then again no exception is thrown -- everything runs ok but we just have an empty scene with nothing to draw!

I've only tried this on the simple hello world demo. I haven't tried the other demos yet -- no point really since the basic functionality of scene rendering is bombing out.

Any assistance and suggestions are appreciated. After trying and experimenting for a few days, I could really use some help on how to continue debugging this issue.

Thanks[/url]

[Mikhail9]

This reminds me of a question I had before. With no criticism intended, because I love using Irrlicht and I'm grateful that it exists, I am curious as to why it should have errors (warnings maybe, but errors?) when building on other compilers? Is it not ANSI C++ with the exception of the DirectX and OpenGL calls?

Or did I just answer my own question?

[vitek]

I think that the maintainers probably don't have access to every compiler out there for porting and they don't have the time to maintain each of those ports and continue to work on bug fixes and enhancement requests. They pick a handful of compilers that they have access to and that people actually use (Microsoft C++ and GNU C++ are very common compilers), so those are the ones that they provide pre-built libraries for.

The code is, for the most part, just plain C++. There are some platform specific things in there (declspecs and a calls to non-portable C functions), but none of this is incredibly difficult to overcome. The source code and makefiles are provided, so porting should be a snap. I'm sure if someone wanted to do a port that the maintainers would accept the patches.

Travis

[Greatwolf]

I believe someone already has, at least for the borland compiler. A search for borland turns up ecopter and someone else on this forum who did the needed changes so that irrlicht will build properly with the bcc compiler.

Unfortunately this is not activately maintained with the main build. The latest one I could find was for irrlicht 1.4.

[hybrid]

The borland code was merged with core Irrlicht, so all those things are available in the latest SDK. However, we cannot fix newly introduced things as long as no one tells us about the errors with other compilers.

[Greatwolf]

Thank you, I wasn't aware of that.

Ok, I got a little further in my attempts. After looking at the irrlichtdevice class, it turns out it also inherits from the IRefcount class. What I didn't realize was that IRefcount isn't really an abtract interface class -- it contains an actual implementation with inline methods and everything.

That explains why I was seeing those crashes. There are 2 copies of IRefcount being compiled, one for my test executable and one on the dll side. The layout of the irrlichtdevice class and it's underlying offsets and vtables with thusly also be different.

I'm still trying to figure why the scene manager is crashing though when it comes time to actually draw stuff to the screen. If the scene doesn't have anything to draw (e.g. camera isn't pointing at the scene objects or there are no scene objects) the drawall() method doesn't crash.

I'm hoping someone familiar with the source could provide some insight on what might be going wrong.

I do have one other question, completely unrelated to the topic at hand: how come the irrlicht.dll built with gcc is so much bigger than the irrlicht.dll built with msvc?

Thanks

[Greatwolf]

Just thought I'd do one more follow-up for my thread to bring this to a conclusion. I have finally resolved all of the visible crash issues.

The root cause of all these crashes, as it turns out, is because specifically borland compilers have floating point exceptions turned on when linking with the default runtime library. This is different from the other compilers that have floating point exceptions suppressed by default, e.g. msvc and mingw-gcc compilers. As such, the runtime environment for the executable ends up being slightly different.

After diagnosing and fixing this subtle issue, by turning off fp exceptions via the _control87() function, I am happy to say all the demo programs compile and can run properly without all the mysterious and bizzarre crashes! So I'm happy and relieved that it all works out at the end.