meson: G_HAVE_GROWING_STACK defined differently
I tried building GLib 2.58.1 Debian packages (with a backport of @xclaesse's fixes for #1527 (closed)) with both Autotools and Meson, and running diffoscope on the results (if you do this, you'll want to use
--exclude-command objdump --exclude-command readelf to avoid spending a long time analyzing some uninteresting differences).
One difference is that
G_HAVE_GROWING_STACK is defined differently. In Autotools, it's always defined to a boolean value: 1 if the stack grows upwards (true on Debian's obsolete HPPA port, and presumably other HPPA OSs), or 0 if it grows downwards (true on every other Debian architecture and probably pretty much everywhere else):
»·······case x$g_stack_grows in »·······xyes) echo "#define G_HAVE_GROWING_STACK 1" >>$outfile ;; »·······*) echo "#define G_HAVE_GROWING_STACK 0" >>$outfile ;; »·······esac
This is appropriate if its value will be tested with
#if G_HAVE_GROWING_STACK (but not for
However, in Meson, it's undefined on x86_64 (and presumably every other relevant architecture), and presumably defined to either 1 or the empty string on HPPA. The relevant section of the diff between versions of
glibconfig.h on x86_64 looks like this:
│ │ │ │ -#define G_HAVE_GROWING_STACK 0 │ │ │ │ +#undef G_HAVE_GROWING_STACK
This would be correct if it was going to be tested with
#ifdef G_HAVE_GROWING_STACK, but not for
I would expect the definition of
G_HAVE_GROWING_STACK to be consistent between Autotools and Meson.
This macro is undocumented and has no uses within GLib, but according to codesearch.debian.net it is referenced by a few language bindings: libgtkada, gtk-d and lazarus. However, it seems to take a nonsensical hard-coded value in all of those, and codesearch.debian.net doesn't detect any uses of the macro, so perhaps it would make most sense to just delete it?