gmtime_r

[Ken Raeburn]

On May 12, 2005, at 18:35, Phil Dibowitz wrote:
> Hey folks,
>
> I'm compiling 5-1.4.1 on Solaris 9 and I get:
>
>   WARNING: Some functions that are needed for library thread
>   WARNING: safety appear to be missing.
>   WARNING:   missing thread-safe function: gmtime_r
>   WARNING: Without these functions, the installed libraries
>   WARNING: may not be thread-safe.
>
> This is _really_ strange since:
>
> 1. gmtime_r() is part of time.h
> 2. This didn't happen on 1.3.3, I just went back and checked.

> The config.log doesn't give any sort of useful information on how it 
> arrived
> at this decision, it just says:
>
>   configure:8373: checking for gmtime_r
>   configure:8435: result: no

If that's all it shows, that probably means that on this invocation of 
configure, it picked up a setting of ac_cv_func_gmtime_r from 
config.cache, and thus didn't attempt to find it again.

It gets a bit more complicated:

The top-level configure script uses AC_CHECK_FUNCS, which uses its own 
declaration of the function it's testing (and in fact goes out of its 
way to *hide* any declaration in the few system headers it uses, in 
case they conflict), so it's testing for the availability of a symbol 
by that name in the current set of libraries, not for a header-file 
declaration or macro.

However... gmtime_r on different systems has different return types.  
On some systems it returns a pointer, and on some it returns an int.  
If we're going to use it, we need to figure out the type it returns.  
There's some code in include/configure(.in) that tries compiling a 
couple of different declarations of gmtime_r, while including time.h.  
If exactly one of them compiles, then we know which type it returns; 
otherwise, I have it setting ac_cv_func_gmtime_r to "no", and we 
pretend the function isn't there.  So that may be how the "no" setting 
wound up in the cache.  (I just ran a test on my Solaris system, using 
gcc as the compiler, and both versions compiled without complaint.  
That means the test failed to determine the return type.)

I admit, the wording of the messages could better handle this case... 
and it would probably be good to do the return-type tests before 
printing out the messages from the top-level configure script, and 
maybe even do all the testing in one place instead of two...

As for the reason it's failing to determine the return type, it looks 
like gmtime_r is only declared if _REENTRANT is defined.  With our 
current configuration framework, causing that to be defined would be 
easy; causing it to happen without forcing the pthread library to be 
linked into every Kerberos program may be hard.  But as a workaround, 
you could try (in a fresh tree):

   configure --prefix=... CPPFLAGS=-D_REENTRANT

and I think that'll probably fix the gmtime_r return type problem.

> I'm not keen on my KDC crashing due to lack of thread saftey.

The KDC itself -- in fact, all of the programs we ship -- is 
single-threaded.  The thread safety issues are for programs like web 
browsers or ldap or imap servers that might be linked against the 
Kerberos and GSSAPI libraries.

Ken