Niko Tyni of Debian points out that the size of the interpreter structure
differs between plain and -DDEBUGGING builds, and that this breaks binary
compatibility of XS modules between such builds. Making the definition of
PL_memory_debug_header unconditional on PERL_TRACK_MEMPOOL (which itself is
defined only on debug builds) eliminates this needless incompatibility.
There is some confusion about whether plain and debug builds are expected to
be compatible. Commit
1e8125c621275d18c74bc8dae3bfc3c03929fe1e (July 2010)
refers in passing to "binary incompatible perls with the same API version
(i.e. the same perl version configured with and without DEBUGGING)". But
f2b88940d815760ad254d35a0ee1eb2ed8ce7762 (November 2009) says explicitly
that "-DDEBUGGING and not need to be binary compatible with each other", and
I think this explicit statement is a better example to follow.
Further, this compatibility is clearly useful for our downstream packagers
(as reported by Niko), and for any users who'd like to be able to use a
debug build for tracking down problems (including those encountered while
using modules with XS parts).
-#ifdef PERL_TRACK_MEMPOOL
-/* For use with the memory debugging code in util.c */
+/* For use with the memory debugging code in util.c. This is used only in
+ * DEBUGGING builds, but defining it in non-debug builds too means that we
+ * retain binary compatibility between otherwise-compatible plain and debug
+ * builds. */
PERLVAR(I, memory_debug_header, struct perl_memory_debug_header)
PERLVAR(I, memory_debug_header, struct perl_memory_debug_header)
#ifdef DEBUG_LEAKING_SCALARS_FORK_DUMP
/* File descriptor to talk to the child which dumps scalars. */
#ifdef DEBUG_LEAKING_SCALARS_FORK_DUMP
/* File descriptor to talk to the child which dumps scalars. */