After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711871 - Broken and misleading configure check for growing stack
Broken and misleading configure check for growing stack
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-11-11 23:07 UTC by Michael Forney
Modified: 2013-11-24 01:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Forney 2013-11-11 23:07:03 UTC
Currently, in the configure check for a growing stack pointer, the test returns 0 (success) when the stack doesn't grow, and 1 (failure) when it does. This is fine because glib_cv_stack_grows is set to no on the success condition and yes on the failure condition, but is misleading because configure prints "checking for growing stack pointer... yes", when in fact the stack pointer does not grow.

However, more importantly, the configure sets the header define G_HAVE_GROWING_STACK using the variable g_stack_grows, but this is before g_stack_grows is even assigned.

So, on my system without a growing stack pointer, configure prints "checking for growing stack pointer... yes", and sets G_HAVE_GROWING_STACK to 1!
Comment 1 Michael Forney 2013-11-24 01:46:21 UTC
Hi,

Thanks for looking at this, but I don't think the issue is fixed, unless I am misinterpreting what you mean by "growing stack".

I would assume that a growing stack means that as the stack gets deeper, the stack pointer gets larger. However, even though the configure script now prints a message consistent with what it sets glib_cv_stack_grows to, it now appears to be testing for a shrinking stack (glib_cv_stack_grows = yes when b <= a). Maybe it would be less confusing if instead of "return b > a", it was "return b > a ? EXIT_SUCCESS : EXIT_FAILURE"?

Additionally, the issue of using g_stack_grows before it is set still remains, so the result of this test is unused anyway.