Hi Bruno, * Bruno Haible wrote on Wed, May 03, 2006 at 10:39:06PM CEST: > Paul Eggert wrote: > > I don't know of any hosts that have multithreading and localtime but > > lack a working localtime_r. > > HP-UX 11.00 with HP/PA. > HP-UX 11.23 with IA64. > > In both cases: > checking whether localtime_r is compatible with its POSIX signature... no
Yes, but the reason this fails is because some extension isn't turned on (ia64-hp-hpux11.23): | configure:53740: checking whether localtime_r is compatible with its POSIX signature | configure:53764: cc -c -g conftest.c >&5 | "conftest.c", line 178: warning #2047-D: incompatible redefinition of macro "fnmatch" (declared at line 170) | #define fnmatch posix_fnmatch | ^ | | "conftest.c", line 390: error #2020: identifier "localtime_r" is undefined | struct tm * (*ptr) (time_t const *, struct tm *) = localtime_r; | ^ | | 1 error detected in the compilation of "conftest.c". and not because the signature is wrong. (Excerpt from a gnulib-all-test done a couple of months ago; no, I never found the time to analyze more than a few issues of it; it would be really helpful if gnulib-tool could actually create a dummy-all test on its own, including all *tests modules, without the need for lots of manual tweaking.) > > The problems that I know of in this area > > typically are namespace problems, where the system has a localtime_r > > but refuses to let you see it unless you utter the appropriate > > mumbojumbo. In this case I'd prefer the bug to be exposed to the > > installer (so that they can use the appropriate compiler flags), > > rather than worked-around with a replacement involving a global lock, > > since the system's localtime_r undoubtedly will be better than our > > replacement. > > The header on HP-UX 11 looks like this: > Since I cannot see how a function can return a pointer and an int > simultaneously, > and since I've no idea when _PTHREADS_DRAFT4 is defined, I wouldn't trust the > system's localtime_r function here. Unless you have other evidence that the function is broken, this isn't really a reason to not trust the function, right? I mean, hey, glibc headers at one point looked ugly, too. Cheers, Ralf
