Unable to build Ogre in Debug mode on Windows

Problems building or running the engine, queries about how to use features etc.
rosenbsn
Gnoblar
Posts: 2
Joined: Sat Feb 07, 2026 7:05 pm

Unable to build Ogre in Debug mode on Windows

Post by rosenbsn »

Ogre Version: 14.5.2
Operating System: Windows x64
Render System: Default found in Ogre make file config

Unable to build Ogre in debug mode using Windows x64 and Visual Studio Community 2026 Release - amd64 kit
The libraries that are failing to build are as follows with example linker errors:

  1. assimp-vc145-mt.lib

    Code: Select all

    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in AssimpLoader.obj
    error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in AssimpLoader.obj
    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in AssimpLoader.obj
    error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in AssimpLoader.obj
    
  2. pugixml.lib

    Code: Select all

    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DotSceneLoader.obj
    error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in DotSceneLoader.obj
    
  3. BulletDynamics.lib

    Code: Select all

    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in OgreBullet.obj
    error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in OgreBullet.obj
    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in OgreBullet.obj
    
  4. BulletCollision.lib

    Code: Select all

    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in OgreBullet.obj
    error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in OgreBullet.obj
    error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in OgreBullet.obj
    

I tried changing the CMAKE_BUILD_TYPE to Debug with no luck. The tools uses are CMake.exe and Visual Studio Community Addition.

Any help would be appreciated.

rosenbsn
Gnoblar
Posts: 2
Joined: Sat Feb 07, 2026 7:05 pm

Re: Unable to build Ogre in Debug mode on Windows

Post by rosenbsn »

I also ran across this post: Errors building OGRE 1.12.2 in Visual Studio 2019 viewtopic.php?t=95415

I tried following its instruction regarding using CMAKE to build Ogre in a release and debug build folder with no luck.

chilly willy
Halfling
Posts: 82
Joined: Tue Jun 02, 2020 4:11 am
x 27

Re: Unable to build Ogre in Debug mode on Windows

Post by chilly willy »

Looks like this is related to this. Maybe some info there will help...

rosenbsn
Gnoblar
Posts: 2
Joined: Sat Feb 07, 2026 7:05 pm

Re: Unable to build Ogre in Debug mode on Windows

Post by rosenbsn »

I followed the instructions from the https://github.com/OGRECave/ogre/issues/1303 with no luck. I still get the same errors.

One thing that should be noted is that in CMake I am using the "Visual Studio 18 2026" generator. Is that Ok? I did try 17 with no luck

Last edited by rosenbsn on Tue Feb 10, 2026 4:36 am, edited 1 time in total.
rpgplayerrobin
Bugbear
Posts: 805
Joined: Wed Mar 18, 2009 3:03 am
x 467

Re: Unable to build Ogre in Debug mode on Windows

Post by rpgplayerrobin »

Even my guide (viewtopic.php?p=554037#p554037) has those errors.
I simply ignore them since the release version works, and that I do not use those libraries/projects anyway in my project in any way.

But from the errors, it seems that Assimp/PugiXML/Bullet are only built in release or that the compiler in debug is trying to link to the release libraries of them instead of the debug ones.
Maybe you can go into Visual Studio and manually check how the libraries that fail are imported from those? Because they should import the debug ones in the debug version and the release ones in the release version, but right now they are always using the release versions for some reason.