Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!

[Paul Smith <psmith gnu org>]

On Fri, 2008-01-18 at 16:34 -0500, Jeffrey Stedfast wrote:
> On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote:
>     > I'm getting a build failure in Evo and gtkhtml with the latest glib: 
> >         editor-control-factory.c: In function 'editor_get_prop':
> >         editor-control-factory.c:463: error: expected _expression_ before 'do'
>     > Apparently, the latest glib broke the libbonobo from Gnome 2.20, so if
>     > you install the latest glib you also need the latest libbonobo.
>
>
>     you might want to warn the glib guys about this then... seems they have broken API or ABI which is a strict no-no.

I'm happy to do this, but the change is not so straightforward.

The deal is this: in the old glib, g_assert() macros were surrounded by G_STMT_START and G_STMT_END macros to make them look like single statements even though they contain multiple statements.  The statement start/end macros back then had a little ifdef dance taken from Perl, which used GCC special features if you built with GCC, or the old do {} while(0) trick if that was checked for in the configure file, or if none of that were true, the relatively obscure "if (1) ... else (void)0" syntax.

For all Gnome builds, obviously, the GCC special capability was used.

Now, libbonobo used the g_assert() macros inside macros of their own, that looked like this:  (g_assert(...), some_other_statement()).  This is a statement that returns a value, rather than the traditional do{}while(0) etc. methods that can only be used in a void context.

When you compiled all of this together with GCC it worked, because the GCC macro extension used by g_assert() provides for the macro to be used as an rvalue.  If you would compile this with any compiler OTHER than GCC, it would not work because you can't use a while loop inside a comma _expression_ like libbonobo is trying to do.

It's arguably a bug in libbonobo that it REQUIRES the use of GCC.

Anyway, for some reason in the newer versions of glibc the g_assert() macro (and all its brethren) were (a) moved to a new header file gtestutils.h, and (b) all the special Perl magic macro stuff was removed and it uses plain do{}while(0) now.  That will work the same way for all compilers, but it breaks libbonobo's use.

The newer versions of libbonobo have changed their macros to use the GCC syntax directly, inside their own ifdef checking for GCC.  If GCC is not set, they don't call g_assert() at all.  This will now compile correctly even on non-GCC compilers.


Soooooo... the old way was definitely broken: probably the real bug was in libbonobo though.  The new glib does change the API for g_assert() _BUT_ only in such a way that shouldn't matter to any correct usage of the macro (since any noticeable difference would have depended on using a specific compiler).