Re: Compiling Pango/GTK+/ATK with -D_REENTRANT but without -lgthread

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi,

> > currently pango builds without -D_REENTRANT, whereas atk and gtk+ 
> > build with
>                                                                ^^^^
> 
> I don't see that GTK+ is being build with -lgthread - I think it is
> just being pulled in via ATK.

Ah, right.

> > Now there are 3 possibilities to solve that:
> >
> > 1.) Replace the search for GLib in pango/atk/gtk+ by
> >
> >     AM_PATH_GLIB_2_0($GLIB_REQUIRED_VERSION, :,
> >                      AC_MSG_ERROR([get a grip]),
> >                      gobject gmodule)
> >
> >     GLIB_CFLAGS = `$PKG_CONFIG --cflags gobject-2.0 gmodule-2.0 \
> >                    gthread-2.0`
> >
> >     This is ugly, because here we write gobject and later gobject-2.0.
> >     So I wouldn't call this a nice solution.
> 
> Calling pkg-config separately is necessary in any case to suppress
> duplicates; take a look at how I have the configure checks set up in
> GTK+. I would consider them to be authoritively correct (except
> perhaps in the matter of -D_REENTRANT.)

It might be correct. The problem I see is that we accept gmodule etc.
_without_ '-2.0' in AM_PATH_GLIB_2_0, but after that you have to pass
gthread-2.0 _with_ '-2.0'. That's just inconsitent, as nearly every library
using GLib will have to call both versions. So either remove the automatic
postfixing in AM_PATH_GLIB_2_0, or allow it for getting @G_THREAD_CFLAGS@ as
well. So I'm not opposed to calling PKG_CONFIG, just doing it with parameters
consistent to AM_PATH_GLIB_2_0.

> > 2.) Make @G_THREAD_CFLAGS@ (normally -D_REENTRANT) mandatory for
> >     GLIB_FLAGS. That would make sense for libraries, might however not
> >     fit applications too well. Then we could simply write
> >
> >     AM_PATH_GLIB_2_0($GLIB_REQUIRED_VERSION, :,
> >                      AC_MSG_ERROR([get a grip]),
> >                      gobject gmodule)
> 
> I don't think this is a good idea; while -D_REENTRANT has virtually no
> effect for GNU libc (and it thus doesn't hurt to include or omit it),
> it might be a signficant speed hit for other systems.

Agreed.
 
> > 3.) Add an extra argument to AM_PATH_GTK_2_0 and AM_PATH_GLIB_2_0 to
> >     pass over additional modules for GTK_CFLAGS resp. GLIB_CFLAGS.
> >     That would allow us to write
> >
> >     AM_PATH_GLIB_2_0($GLIB_REQUIRED_VERSION, :,
> >                      AC_MSG_ERROR([get a grip]),
> >                      gobject gmodule, gthread)
> >
> >     All in all this seems to be the best solution to me. A patch to
> >     glib/m4macros/glib-2.0.m4 is appended to demostrate, what I mean.
> 
> Well, since GTK+ doesn't actually use the cflags coming out of
> AM_PATH_GLIB_2_0, this wouldn't help for it. (And Atk is basically
> set up the same way.)

I see.

So I would suggest replacing (in glib/m4macros/glib-2.0.m4)

  pkg_config_args=glib-2.0
  for module in . $4
  do
      case "$module" in
         gmodule) 
             pkg_config_args="$pkg_config_args gmodule-2.0"
         ;;
         gobject) 
             pkg_config_args="$pkg_config_args gobject-2.0"
         ;;
         gthread) 
             pkg_config_args="$pkg_config_args gthread-2.0"
         ;;
      esac
  done

by 

  pkg_config_args="glib-2.0 $4"

as the cleanest solution.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi