When using GCC, given that I compile the same library sometimes in release and sometimes in debug, is the ABI guaranteed to be compatible?
(while using the same compiler)
I have an executable and some shared objects (some depend on others), I want to be able to swap out release/debug shared objects without recompiling everything but only the shared objects in interest.
Is this possible, or is there some scenario where I might get some undefined behavior this way? (Assuming my code is strictly packed, and padded in both release and debug)
EDIT:
I'll elaborate on the problem we're seeing. We have a custom version of intrusive_ptr
, in debug mode we have our own intrusive_ptr
which has a single member that is a boost::intrusive_ptr
, and in release we simply use boost::intrusive_ptr
. The API of our intrusive_ptr
is the same of boost::intrusive_ptr
, and we don't have any virtual functions in the class.
What we are seeing is this:
If we use all debug libs or all release libs all works well. If we mix debug executable with release libs, there is a memory leak from the intrusive_ptr
and it does not release the object.
The sizeof our intrusive_ptr
and boost::intrusive_ptr
are identical, both in debug and release (our class does not add any size overhead on top).
So I am wondering what could be causing the leak, ABI difference are the only things that come to mind.
Ideas?
I have known several compilers that generate incompatible code for release and debug (though these compilers are long since deprecated). In face I would not trust object modules to fully compatible unless they have been compiled with Exactly the same flags.
This is why makefiles (following GNU principles) and IDE like Eclipse build release/debug/profile objects into different directories. To make sure that they can never be mixed up.
Typically no, because the usual difference between a release and a debug build are just options to make debug stepping works better. But unexpected behavior is still possible, if you define other options differently (such as integer size, target architecture, ??) between the release and debug builds, the caller parameters may not match the callee expectations. There could also be issues with exception safety, and const-ness that the run time linker may not check.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With