Issue
This question has been asked a href="https://stackoverflow.com/questions/5771935/c-linking-release-built-library-with-my-debug-build">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:
- Is it different between Windows and Linux?
- If it is also undefined behavior in Linux, how come it doesn't fail at build time?
- Is it different between static and shared libraries?
- 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...
Solution
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.
Answered By - spectras Answer Checked By - Marie Seifert (WPSolving Admin)