Upgrading to 0.4.2

[tstuefe]

@Descend:

The only thing I've got to go on here is that it is looking for the function:
?createDevice@irr@@YAPAVIrrlichtDevice@1@W4EDriverType@video@1@ABV?$dimension2d@H@core@1@I_N2PAVIEventReceiver@1@PB_W@Z

But in the actual DLL (Opened using PE Viewer) the function is
?createDevice@irr@@YAPAVIrrlichtDevice@1@W4EDriverType@video@1@ABV?$dimension2d@H@core@1@I_N2PAVIEventReceiver@1@PBG@Z

Notice the only difference is PB_W and PBG ... I have no idea what that means though if it means anything at all!

Thats the C++ name decoration you are looking at. In C++, symbols are exported using the not only the name, but also a hashed string which contains interface information. In 0.4.2, the interface for createDevice differs, it got one new parameter, hence the difference in the mangled name. That's why the linker refuses to link against the lib.

The second symbol, "...ceiver@1@PBG@Z", is the current export in 0.4.2, which is okay.

What is weird though is that "...@1@PB_W@Z" part in your first symbol. I looked at the exports of all dlls/libs in 040/042 for both DevCpp and VC, none of them exported this symbol.

Where did you get this "...@1@PB_W@Z" symbol from? I assume its from your application object file?
If that is the case the compiler "saw" a different createDevice prototype when compiling your application object, and this can happen when e.g.:
1) you used a wrong, maybe modified headerfile irrlicht.h with a different version of createDevice. Maybe your irrlicht.h is way outdated (pre 0.4.2)? Or Niko somehow, at some point in time, shipped a wrong version of this header file and your got a "bad" shipment?
2) you somehow managed to redefine part of the interface, maybe via a macro? So that the last parameter becomes something different and thus causes a different symbol. To check this, preprocess your application c++ file and check the *.i file - how does your createDevice call look after the Preprocessor run over it?
3) Another possibility is your compiler has a bug. The symbol looks like it was generated by VC++. If you pull in the right header and the header is correct, then the symbol should look like your second symbol. If not, the compiler is somehow broken. For VC++, try to get the latest service pack (I think it is #5 for VC60).

Also, check the "dumb" errors:
- do you really have the latest include files (and the latest libs/dlls, though I don't think thats the problem)? When in doubt, download them freshly.
- does the prototype for createDevice in your version of irrlicht.h look like this

Code: Select all

	IRRLICHT_API IrrlichtDevice* createDevice(
		video::EDriverType deviceType = video::EDT_SOFTWARE, 
		const core::dimension2d<s32>& windowSize = core::dimension2d<s32>(640,480),
		u32 bits = 16,
		bool fullscreen = false,
		bool stencilbuffer=false,
		IEventReceiver* receiver = 0,
		const wchar_t* sdk_version_do_not_use = IRRLICHT_SDK_VERSION);

- is your include path set right so that you pull in the right include files? When in doubt, preprocess your application C++ file and check whether your prototype of createDevice looks like the code above.

If nothing helps, rebuild both irrlicht.dll and your application completely from scratch - using the same compiler.


hoe that helps,


thomas

[Descend]

I've cracked it!

Finally got it to compile and run. If you experience this problem in MSVC 7, go into your project configuration properties and select C/C++ then Language. In there is a setting titled 'Treat wchar_t as Built-in Type'... if this is set to Yes, you get the problem. Change it to No and hey presto, it works.