Re: glib (2.0) fixes and darwin porting
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: Gtk Development List <gtk-devel-list gnome org>
- Subject: Re: glib (2.0) fixes and darwin porting
- Date: Wed, 18 Apr 2001 14:58:07 +0200
Hi Dan,
> > > - 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?
That indeed sounds like it should work. I implemented that and tested it on
Solaris, Linux and HP. There it works like expected.
> 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...
Yeah, thats really annoying, but I'm not completely sure, that another
function will have a consistent prototype either. But we'll simply try another
one, namely localtime_r, waiting for error reports for that.
Attached is a patch to solve that very problem. Please have a look. I would
commit it unless there are any objections.
Bye,
Sebastian
--
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi
Index: configure.in
===================================================================
RCS file: /cvs/gnome/glib/configure.in,v
retrieving revision 1.190
diff -u -b -B -r1.190 configure.in
--- configure.in 2001/04/17 00:55:34 1.190
+++ configure.in 2001/04/18 12:32:31
@@ -1004,17 +1004,22 @@
G_THREAD_CFLAGS="$G_THREAD_CFLAGS -D_POSIX4A_DRAFT10_SOURCE"
esac
- # if we are not finding the ctime_r function, then we probably are
+ # if we are not finding the localtime_r function, then we probably are
# not using the proper multithread flag
glib_save_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $G_THREAD_CFLAGS"
- 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))])
+ # First we test, whether localtime_r is declared in time.h
+ # directly. Then we test wether a macro localtime_r exists, in
+ # which case localtime_r in the test program is replaced and thus
+ # if we still find localtime_r in the output, it is not defined as
+ # a macro.
+
+ AC_EGREP_CPP([^a-zA-Z1-9_]localtime_r[^a-zA-Z1-9_], [#include <time.h>], ,
+ AC_EGREP_CPP([^a-zA-Z1-9_]localtime_r[^a-zA-Z1-9_], [#include <time.h>
+ localtime_r(a,b)],
+ AC_MSG_WARN($FLAG_DOES_NOT_WORK)))
CPPFLAGS="$glib_save_CPPFLAGS"
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]