GNOME Bugzilla – Bug 340590
<time.h> in date.c still not right
Last modified: 2009-08-21 15:55:12 UTC
This is a continuation/reopening of Bug #138095, Bug #138095, Bug #150844, Bug #332173. Using libxslt-1.1.15 and 1.1.16, libexslt/date.c still emits: date.c:765: warning: implicit declaration of function 'localtime_r' date.c:784: warning: implicit declaration of function 'gmtime_r' on Mac OS X (both 10.3 (darwin7.9.0, gcc3.3) and 10.4 (darwin8.6.1, gcc4.0.1)). The config.h does #define HAVE_TIME_H and therefore date.c does #include <time.h>. However, the config.h also does #define HAVE_LOCALTIME_R and therefore date.c does #define _POSIX_SOURCE. That's bad.../usr/include/time.h has: #if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE) struct tm *gmtime_r(const time_t *, struct tm *); struct tm *localtime_r(const time_t *, struct tm *); #endif /* neither ANSI nor POSIX */ so those functions do not get declared. #undef'ing _POSIX_SOURCE clears the warnings. The comment in date.c about _POSIX_SOURCE says that the #define is needed for gnu libc, which is quite unlike my kernel. Should configure have a test to determine whether _POSIX_SOURCE is needed to get those symbols?
Still present in libxslt-1.1.20...
*** Bug 551835 has been marked as a duplicate of this bug. ***
Still present in libxslt-1.1.24 Alright, this bug-report is now over two years and nine release-versions old. Could I get any comment at all from devs here?
Well ... provide a patch and you will have a comment faster. None of the developpers have a Mac OS X box. Plus it's only a warning and things do compile, it's a cosmetic issue and I would expect a patch if you really cared. Now I don't see why it's bad for libxslt to: - set #define HAVE_TIME_H since there is <time.h> on the system - set #define HAVE_LOCALTIME_R since the system defines localtime_r - #define _POSIX_SOURCE since we are running POSIX if there is a macros to detect your system it would be trivial to add it around #define _POSIX_SOURCE as was done for AIX when someone submitted a patch ! Provide the 2 line patch and it will be fixed in the next release ! But expecting the devels to go hunt the specifics of your system when say system is even shipping libxslt by default and we never received a portability patch from them is just unreasonnable, and complaining about the lack of feedback just mean we have most pressing issues and work to do ! That simple, nothing personal Daniel
I didn't take it personally (and neiher I nor my vendor expect to be -Werror clean because darwin has so many unlike-others'-header-games header-games). However, I don't bother following up with attempts to fix unless I get a bite from devels when I ask for info/sketch out a fix, etc. In general, #defining any of the _*_SOURCE tokens on darwin breaks things often and fixes things rarely, so my first inclination is always to figure out what/why/where it is needed. Seems like moving up to OS X 10.5 time.h changes the token effects further and I think the warning is cleared there. Now that OS X 10.3 is long-dead and 10.4 is presumed EOL within a few weeks when 10.6 comes out, I will wait until then to see what (if any) platform-token test or similar patching is needed for current kernel versions and follow up...
Okay, if you have a patch, I take it, if you think the issue is over fine too, reopen if you want this changed, Daniel