Re: glib (2.0) fixes and darwin porting

[Dan Winship <danw ximian com>]

> > -    AC_TRY_COMPILE([#include <time.h>],
> > -       [time_t t; char b[30]; ctime_r (&t, b);], ,
> > -           [AC_TRY_COMPILE([#include <time.h>],
> > -               [time_t t; char b[30]; ctime_r (&t, b, 30);], ,
> > -                       AC_MSG_WARN($FLAG_DOES_NOT_WORK))])
> > +    AC_EGREP_CPP(ctime_r, [#include <time.h>], ,
> > +       AC_MSG_WARN($FLAG_DOES_NOT_WORK))])
> 
> Is that necessary for Darwin? I rememver to have changed it that way to make
> it also recognise macros and not only function declarations of that name. I
> would really like to keep it that way.

It's not a Darwin-related issue. The existing test just doesn't do what
it claims to do, because if G_THREAD_CFLAGS doesn't cause ctime_r to be
prototyped, the AC_TRY_COMPILE will succeed (just with a warning about
ctime_r not being declared).

One way to fix this to work with a macro too would be to first do the
AC_EGREP_CPP to see if time.h defines a function ctime_r, and then do
another AC_EGREP_CPP for [^a-zA-Z_]ctime_r[^a-zA-Z_] on a program that
uses ctime_r, and if the AC_EGREP_CPP fails, then the use of ctime_r was
replaced by something else, meaning ctime_r was defined as a macro. I
think that should work?

Is there any reason for using ctime_r in particular? It would be nice to
do it with something that has a consistent prototype across platforms so
you don't need the separate 2-arg and 3-arg tests...

-- Dan