DLL Debug vs Release

[bibiteinfo]

Ok, there's something I don't understand fully and need highlight on it.

I've setup my project with a DLL (Irrlicht) by linking it with the .lib and my project run in both debug/release with no problem.

Then I take Ogre, and I try to link both debug/release with the release DLL, it crash in debug mode. I've put all the projects settings the same as the one in Irrlicht and still crash. So I need to take the Ogre debug DLL. My main problem here is the size of that DLL which is over 20Mo and I don't want to put it on my SVN.

How should I workaround this?

Thanks

[jacmoe]

IMO, it's bad practice to even think of including binary out put files in a SVN repository.
If people need Ogre or Irrlicht, let them get it.
You are not allowed to redistribute debug binaries using Visual Studio, by the way.

[bibiteinfo]

Well Ogre is doing it, isn't it? I mean when I download OgreSDK, there is the CEGUI debug DLL coming up with.

And I'm putting it on SVN for it not being a showstopper. I just want the people to hit F5 and it compile and run really easily.

[jacmoe]

The difference is that Irrlichts debug configuration is a lot leaner than the Ogre debug configuration.

[bibiteinfo]

I don't get your point. I just don't understand how one DLL can be used in both debug/release and the other DLL cannot be used in debug/release?

I mean if that was the case that a release DLL never can be used in a debug environment I see a lot of problem which would happened... So there must be a way to use a release DLL in a debug environment, my question is just : How?

[Penguin]

I think what jacmoe is trying to say is that visual studio including something in the debug dll that's against a license to release? I may be wrong though.

[jacmoe]

I don't get your point. I just don't understand how one DLL can be used in both debug/release and the other DLL cannot be used in debug/release?

That really depends on what happens when DEBUG is defined.

[haffax]

bibiteinfo, go to OgrePlatform.h and locate the following:

Code: Select all

// Win32 compilers use _DEBUG for specifying debug builds.
#   ifdef _DEBUG
#       define OGRE_DEBUG_MODE 1
#   else
#       define OGRE_DEBUG_MODE 0
#   endif

Modify it so, that OGRE_DEBUG_MODE evaluates to 0 in any case.
Else many assumptions in Ogre code are not met.

Maybe there is more work to do than that. Never tried it.

[Sacrusha]

I don't get your point. I just don't understand how one DLL can be used in both debug/release and the other DLL cannot be used in debug/release?

Short reply:

My guess is both don't work, but one crashes now, while the other may react weird at some future point in time.

Long reply:

The problem is caused by the header files being interpreted in different ways by the compiler that compiles the dll (with DEBUG flag) and by the compiler that compiles the other project which uses the dll. Due to "#ifdef", the precompiler will hand the compilers two different sets of data, so if you runtime link with the dll the program is pretty much guaranteed to screw up at some point. Generally the result is undefined - if it works you are lucky (or not, considering that it's a timebomb).

A simple example of something that could happen is that it uses one allocator to allocate and a different one to deallocate. This will happen if allocation uses a function call to the dll and deallocation is inline in the header of the library (so there's no call to the dll). Debug builds often use a different allocator than release, to get more information about the heap.


There can be several precompiler defines causing such problems if out of synch, even if the dll and the other project both are debug (or release). An example would be SCL_SECURE on VC8. Differences of some compiler settings are possibly dangerous for this reason as well (/clr on VS 2008 if you're doing interop with .NET causes something similar, for example).

If you work with Visual Studio use Visual Studio Property Sheets to avoid that problem in multi-project development. And never ever mix debug and release builds.

[bibiteinfo]

Thank you for that answer

[Kojack]

Mixing release and debug builds is fine. Many libraries come as release mode dlls only, and they still work fine with debug programs.
Basically, libraries shouldn't use the compiler's debug flag in their headers, because it tells the debug/release mode of the thing including the header, not how the library was built. A better way is to use defines in the project settings to say which way you want it built. Then your main program can add something like OGRE_RELEASE to it's defines and everything should work.
Probably combine it with the way import/export dll info is set up (functions are set to import or export depending on whether it's their own library or another component including them.