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 511975 - g_assert must not use new function
g_assert must not use new function
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-01-25 06:23 UTC by Matthias Clasen
Modified: 2008-06-16 05:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2008-01-25 06:23:58 UTC
We've been burned by this once before. 

If we change the expansion of a (widely used) existing macro to include new api,
hell breaks loose, because suddenly recompiling anything using the macro against
a new glib silently adds a dependency against the new glib version. 

I've seen several problems of this kind in rawhide recently that were caused
by g_assert(). 

Please revert the change to make g_assert and g_assert_not_reached use
the new g_assertion_message... functions. If you have to have a g_assert that
variant that does that, name it something else, say, g_assert_expr() and
g_abort_if_reached()
Comment 1 Tor Lillqvist 2008-01-25 08:57:51 UTC
Umm, hasn't it always been so that compiling against some $current_version headers, regardless if the code actually uses API introduced in $curent_version, still potentially causes a run-time dependency on $current_version? I would say, if one wants to be sure one depends only on some $old_version, then compile against $old_version's headers.
Comment 2 Matthias Clasen 2008-01-25 15:07:06 UTC
Yeah, basically. 

But if you play this trick with widely used macros, the pain is considerable.
Comment 3 Mart Raudsepp 2008-03-13 00:45:31 UTC
Also g_assert moved to a completely different header with no backwards compatibility.
For example inkscapes src/attributes.cpp ends up including glib/gmessages.h to get g_assert definition. Now with glib-2.16 it fails compilation because glib/gmessages.h does not provide a definition for g_assert anymore and does not include directly or indirectly the header that does either.
And including gtestutils.h in gmessages.h isn't a good solution at this point either, as gtestutils.h happily includes the whole of glib.h loosing the whole point that inkscape is doing (including just the header that provides g_assert instead of the whole of glib.h)
Comment 4 Matthias Clasen 2008-03-13 00:58:41 UTC
Selectively including individual headers has never been supported. You are supposed to include glib.h
Comment 5 Mart Raudsepp 2008-03-15 17:10:12 UTC
This was in line with the widely used aspect. gmessages.h was a header that included g_assert and some other debugging facilities, that some things use only. I'm fine with it staying the same - inkscape has gone fixing it meanwhile (but my understanding is they still include individual headers). Thanks for stating that's not supported and I'll go bother inkscape guys about that instead.

Meanwhile we are getting big uproars about everything breaking subtly on a glib downgrade to 2.14, i.e this bug.
Comment 6 Matthias Clasen 2008-06-16 05:40:05 UTC
Too late now, I guess.