On Fri, Jan 25, 2013 at 1:58 AM, Thorsten Glaser <[email protected]> wrote:
> Daniel Schepler dixit:
>
>>cc -DHAVE_CONFIG_H -I. -I../../../lib -I.. -D_FORTIFY_SOURCE=2
>>-D_GNU_SOURCE -DUSE_LIBBSD -g -O2 -fPIE -fstack-protector
>>--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall
>>-fno-strict-aliasing -Wformat -Wno-unused-result -c
>>../../../lib/strftime.c
>>../../../lib/mktime.c: In function 'ydhms_diff':
>
> Is there something garbled in your output? I see strftime.c but
> the error is in mktime.c, and (at least the copy I am looking at
> right now) the former doesn’t #include the latter.
Oh, sorry, my buildd setup sets DEB_BUILD_OPTIONS to "parallel=3", so
the command to compile mktime.c was actually on the line before what I
quoted.
>
>>../../../lib/mktime.c:170:3: error: size of array 'a' is negative
>>make[4]: *** [mktime.o] Error 1
>
> I’d rather know why it tries to build mktime.c at all. You see,
> this flavour of CVS comes from MirBSD, which (on i386) has the
> same situation: sizeof(int) == sizeof(long) == 4, whereas
> sizeof(time_t) == sizeof(long long) == 8.
>
> To get the configure check AC_FUNC_MKTIME passing, I had to fix
> some things in libc first (one of which was to use “time_t” instead
> of “long” for struct tm.tm_year, IIRC). That solved the issue of
> gnulib trying to replace mktime. How about that instead?
Doing a search for mktime in the build log, I see
"ac_cv_func_working_mktime=no" in the configure line... Although even
if I remove that, and force an autoreconf to make sure the mktime test
is up to date, the mktime test times out. Oddly, though, if I extract
that test to a standalone .c file and compile it -O0 then it works,
but if I compile it -O2 it times out again. Putting in debugging
output, it appears it's calling bigtime_test(MIN_INT) and then
bigtime_test(0) repeatedly, so it looks like some compiler bug is
happening here. I'm currently using gcc-4.7 4.7.2-18 from
experimental (or actually gcc-4.7_4.7.2-18+x32 from unreleased which
is an exact copy other than the version). Actually, it looks like I
can even reproduce it just with:
extern int foo();
void test_fn() {
int i;
for (i = 1; 0 < i; i *= 2)
foo(i);
}
I'm going to have to test with the current 4.7.2-19 on amd64 and see
if the problem persists there.
But even with the -O0 version most of the localtime calls are failing
because tm.tm_year is an int in [e]glibc, so it's probably not
actually testing much.
--
Daniel Schepler
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
