gmtime_r

[Ken Raeburn]

On May 13, 2005, at 02:17, Phil Dibowitz wrote:
> So, um, with my patch I get this:
>
>   $ grep gmtime configure.output.log
>   checking for gmtime_r... yes
>   checking for gmtime_r... (cached) yes
>   checking whether gmtime_r returns int... unknown -- ignoring gmtime_r
>   $
>
> But, I no longer get the warning. It's completely unclear to me if I'm
> threadsafe in this circumstance, and in fact it seems like I _should_ 
> get the
> warning in this case - can you explain why I don't?

We've got multiple configure scripts.  The top-level one prints the 
warnings you were referring to originally, and then it runs the 
configure scripts in subdirectories.  The one in the include directory 
has the check for the return type, and alters the setting of the 
variable in the cache that says whether gmtime_r is available.  So, if 
you were to re-run configure from the top level in that tree, with the 
config.cache file present, it should give you the warning the next 
time, because it picks up the override value from the cache instead of 
running the test again.  Kind of screwy, huh? :-(

I'm working on some changes right now to try to clean that up a bit, 
but they probably won't get into any 1.4.x releases we might yet do.

> Also note that I'm not using gcc, I'm using the Forte SparCompilers 
> from Sun -
> version 7.
>
> Anyway, reversing the patch and trying your CPPFLAGS idea, I solve that
> problem:
>
>   $ grep gmtime_r configure.output.log
>   checking for gmtime_r... yes
>   checking for gmtime_r... (cached) yes
>   checking whether gmtime_r returns int... no

That's good news...

> But I also get a lot of this type stuff:
>
>   configure: WARNING: sys/ptyvar.h: present but cannot be compiled
>   configure: WARNING: sys/ptyvar.h: check for missing prerequisite 
> headers?
>   configure: WARNING: sys/ptyvar.h: proceeding with the preprocessor's 
> result
>   ...
>   configure: WARNING: regexp.h: present but cannot be compiled
>   configure: WARNING: regexp.h: check for missing prerequisite headers?
>   configure: WARNING: regexp.h: proceeding with the preprocessor's 
> result

Those come up sometimes ... I think it's usually when we test for one 
header file being present, but it requires that another one be included 
first, which the usual autoconf tests don't do.  I haven't been 
worrying about it myself...

> So is the best bet to configure with CFLAGS and CPPFLAGS? Or to use a 
> patch
> such as the one I made (of which I still don't understand the output 
> from),
> or... ?

For the long term, it's good to fix up the configure scripts, but 
setting CFLAGS or CPPFLAGS should be good enough for the short term.

Ken