Re: [gimp-devel] GTK & GIMP & --enable-ansi

[Owen Taylor <owen gtk org>]

> I'm sending this to the gtk-list and gimp-dev list because the problem
> comes from dependencies between the configure options of GTK and GIMP,
> and I am not sure about which package should solve the problem...
> 
> Here is the story: since the release of GIMP-1.0.0, I have been
> re-installing the latest versions of GTK and GIMP on many
> machines/networks.  Usually, I configure both with --enable-ansi
> because this allows me to see if I am adding any non-portable code
> before submitting some patches.  But on one of the systems on which I
> do not have root access, a recent version of GTK was already installed
> and the GIMP configure script accepted it without problems.  Alas, the
> compilation failed for the following plug-ins: blur, destripe, emboss,
> gfli, nlfilt, ps, randomize, sinus, zealouscrop.
> 
> These errors were caused by the "inline" keyword, because GTK was
> configured with --disable-ansi (I did not know it at that time) and
> GIMP was configured with --enable-ansi.  As a result, the "#define
> inline" did not work correctly and the compilation failed.

To explain what happening in more detail, with the --enable-ansi
flag set, GCC turns of the inline keyword and instead provides
__inline__.

> I think this is a long-standing bug in GTK/GIMP, and I remember seeing
> it a long time ago.  I had not seen it for a while because I always
> configured GTK and GIMP with the same options, but I got hit this time
> with a pre-installed GTK.  Note that the compilation works fine if
> both are configured with --disable-ansi, both with --enable-ansi, or
> if GTK is configured with --enable-ansi and GIMP with --disable-ansi.
> 
> The main problem comes from the fact that the configure script for the
> GIMP (or any other GTK application) has no way to know if GTK was
> configured with or without --enable-ansi.
> 
> It would be possible to avoid this problem by adding an AC_TRY_COMPILE
> with a small program that includes the GTK headers and uses the inline
> keyword.  But I don't like this solution, because this implies that
> the configure script of a GTK application would have to undo and redo
> what GTK is supposed to do correctly in the first place with "#define
> inline..."
> 
> Has anybody thought about a good solution to this problem?

I tend to think that GLIB should not be #defining inline in
glibconfig.h; rather the test should be private to GTK+'s
config.h and the GIMP should use AC_C_INLINE separately.

A slight difficulty is that GLIB wants to use inline itself
in a few places but has no private config.h header file.

The short term solution would be to put AC_C_INLINE in the
GIMP's configure.in file, then in every place inline is needed,
make sure there is an

 #undef inline
 #include "config.h"

This preserves backwards compatibility; since the inline definition
can't reasonably be changed in the 1.0 branch of GTK/glib.


A solution on a different track is to substitute the AC_C_INLINE
autoconf macro with one of our own that instead of checking
for inline keywords in the order

 inline __inline__ __inline

does it in the order:

 __inline__ inline __inline

Since __inline__ should work both with and without --enable-ansi.

Regards,
                                        Owen