Meshlib Debug Version Error

[czc98]

I downloaded the precompiled Meshlib library Release v3.1.3.429, but when I tried to compile in Debug, I got the following error: _ITERATOR_DEBUG_LEVEL is inconsistent with MeshLib.

set(MESHLIB_DIR E:/develop/workspace/third-party/MeshLibDistVS22_v3.1.3.297/install)
set(MESHLIB_INCLUDE_DIR ${MESHLIB_DIR}/include/MeshLib)
set(MESHLIB_LIB_DIR ${MESHLIB_DIR}/lib/Debug)
set(MESHLIB_THIRDPARTY_INCLUDE_DIR ${MESHLIB_DIR}/include ${MESHLIB_DIR}/include/eigen3)
set(MESHLIB_THIRDPARTY_LIB_DIR ${MESHLIB_DIR}/lib/Debug)
...
target_include_directories(${PROJECT_NAME}
    PRIVATE
         ...
        ${MESHLIB_INCLUDE_DIR} 
        ${MESHLIB_THIRDPARTY_INCLUDE_DIR}
)
target_link_directories(${PROJECT_NAME} 
  PRIVATE 
    ${MESHLIB_LIB_DIR}
    ${MESHLIB_THIRDPARTY_LIB_DIR}
)
target_link_libraries(${PROJECT_NAME}
    PUBLIC
        MRMesh
)

development environment: VS 2022

[Fedr]

This is not a broken package — it is a deliberate #error in MeshLib, and it is telling you that your application and the pre-built binaries disagree about _ITERATOR_DEBUG_LEVEL.

Why it happens

A Visual Studio Debug configuration defines _DEBUG, and the Microsoft STL then implies _ITERATOR_DEBUG_LEVEL=2. Non-zero iterator debugging makes MS STL containers dramatically slower, so all MeshLibDistVS* binaries are built with _ITERATOR_DEBUG_LEVEL=0 — that includes lib/Debug and app/Debug, which are otherwise genuine debug builds (unoptimized, with PDBs). Mixing the two values in one process changes the layout of every STL container (sizeof(std::vector<int>) is 24 vs 32, sizeof(std::string) 32 vs 40), so MeshLib catches it at compile time instead of letting you hit heap corruption at runtime:

// source/MRMesh/MRMeshFwd.h
#if !defined MR_ITERATOR_DEBUG_LEVEL
    #define MR_ITERATOR_DEBUG_LEVEL 0
#endif
#if _ITERATOR_DEBUG_LEVEL != MR_ITERATOR_DEBUG_LEVEL
    #error _ITERATOR_DEBUG_LEVEL is inconsistent with MeshLib
#endif

MR_ITERATOR_DEBUG_LEVEL is your acknowledgement: you must set it to the same value you are actually compiling with.

Option A — keep MeshLibDistVS22, turn iterator debugging off in your app

target_compile_definitions(${PROJECT_NAME}
    PRIVATE
        _ITERATOR_DEBUG_LEVEL=0
        MR_ITERATOR_DEBUG_LEVEL=0
)

Your Debug build then matches the shipped Debug binaries. This is what we do in CI when we smoke-test the distribution against examples/cpp-examples. I verified it against MeshLibDistVS22_v3.1.3.429 with VS2022 (v143, cl 19.44), Debug config: builds, links, and runs (makeCube/makeTorus/boolean/fillHole/MeshSave) cleanly.

One caveat: every module of your application (.exe, .dll, .lib) that passes MS STL types across a boundary must use the same value.

Option B — use the debug distribution, and keep iterator debugging

Every release also publishes MeshLibDist_<version>-IteratorDebug.zip, which is built with _ITERATOR_DEBUG_LEVEL=2. Point MESHLIB_DIR at that one, and declare the value you are already compiling with:

target_compile_definitions(${PROJECT_NAME} PRIVATE MR_ITERATOR_DEBUG_LEVEL=2)

(_ITERATOR_DEBUG_LEVEL is already 2 in a Debug build, so only the MR_ macro is needed.) Also verified end to end with VS2022 Debug: builds and runs clean. That package is produced with the v142 toolset and it only ships app/Debug, but mixing its /MDd DLLs into a v143 debug application is fine — both bind the same MSVCP140D.dll / VCRUNTIME140D.dll / ucrtbased.dll, so there is one heap and one set of iterator-debugging bookkeeping.

Important: do not rely on the #error to catch this

The check only fires if some CRT or STL header was included before the first MeshLib header. If a MeshLib header comes first, _ITERATOR_DEBUG_LEVEL is not defined yet, MeshLib defines it to 0 itself, and that translation unit silently compiles at 0 — no diagnostic, and the linker will not object either. Against the -IteratorDebug package that combination builds cleanly and then dies at startup inside the C++ runtime. So please set MR_ITERATOR_DEBUG_LEVEL explicitly, project-wide, rather than treating a successful compile as proof that the values agree.

One more thing

Your snippet points at

E:/develop/workspace/third-party/MeshLibDistVS22_v3.1.3.297/install

but you mention downloading v3.1.3.429. Please make sure the headers and the libs come from the same archive — mixing two versions is a separate failure with much less obvious symptoms.

[czc98]

thanks!