Skip to content
Advertisement

Mixing debug and release libraries: Windows vs Linux, static vs shared

This question has been asked a few times already, but I observe that it always refers to Windows. Which makes sense, given that MSVC fails with the following error:

error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in main.obj

And it seems to me that on Linux, it does not fail at build time.

Answers mention different C++ runtime between the build types and not sharing CRT resources between such libraries. Still, it is not clear to me how different that behavior is in Linux/Windows and with shared/static libraries.

I would like to understand this better. Questions could be:

  1. Is it different between Windows and Linux?
  2. If it is also undefined behavior in Linux, how come it doesn’t fail at build time?
  3. Is it different between static and shared libraries?
  4. Does my Linux package manager download debug versions of all the dev packages? Looking into usr/lib/, I can’t seem to find both release and debug libraries there…

Advertisement

Answer

Yes Linux and Windows are different. I cannot tell much for Windows, but with Linux toolchains we don’t really have a split Debug vs Release build.

What we have is several options:

  • which optimizations are enabled?
  • should debugging symbols be emitted?
  • some other less relevant stuff.

What build toolchain refer as “Release” or “Debug” is just a set of options. for instance, CMake’s min-size release build uses -Os -DNDEBUG, while CMake’s debug release uses -g. Distributions also add additional options when they package stuff.

But other than those options, the ABI is the same, so those are all compatible (except for options specifically marked[*] – but those are not used in typical builds). So it doesn’t matter. You can mix “debug” or “release” objets, it will work.

As for 4), the way a lot of distributions do it is they build with split debugging symbols. That means debugging information is emitted in a separate file, and typically packaged independently. For instance:

ii  libc6:amd64       2.27-3ubuntu1  GNU C Library: Shared libraries
ii  libc6-dbg:amd64   2.27-3ubuntu1  GNU C Library: detached debugging symbols

Second package is normally not installed. I installed it manually to step through libc6 with full debug info.


[*] For an exemple, check out GCC code generation options. You’ll see those that generate incompatible objects have a warning on them.

User contributions licensed under: CC BY-SA
7 People found this is helpful
Advertisement