>
> OK, I'm done now. Can you please try the latest gnulib mktime.c
> and see whether it solves the problem on your platform?
I tested it, and mktime.exe no longer hangs for dates before 1970.
$ ./mktime 1980-01-01 00:00:00
mktime returns 315529200 == 1980-01-01 00:00:00 yday 000 wday 2 isdst 0
> Can you debug the problem, by seeing where the
> loop is in the mktime executable? mktime.c has
> code to detect loops (look for the comment that
> mentions "oscillating") but evidently it is not
> working in your environment.
I stepped through the executable once for 1970-01-01 01:00:00 (which
> | So currently, it would require unistd.h to be either included twice,
> | or be included before winsock2.h to work properly.
>
> I think it would be OK if we had to include unistd.h before
> winsock2.h.
I don't agree.
How do you know whether winsock2.h has already been included?
In the current
Hello list,
building octave for MinGW platform currently encounters compilation
errors in connection with gnulib's unistd.h header file.
Currently octave includes (among other headers), and then
uses e.g. gnulib::gethostname(), but g++ complains about gethostname
not beloning to namespace gnulib
Hello list,
Using gnulib's mktime on MinGW platform, I found that a call to
mktime() hangs for dates before 1970-01-01 01:00:00.
To reproduce, I compiled mktime.c into an executable file as
instructed at the bottom of the source code.
> mktime 1970-01-01 01:00:00
mktime returns 0 == 1970-01-01 01
> Looks like reasonable behavior to me. Actual comments on the patch:
Thanks for the feedback, I appreciate all hints.
And thanks for pushing the fix into the repository.
benjamin
Apology for the delay,
>> I'd like to push this in your name, once I have your okay. The
>> (tiny change) notation reflects your copyright status, and is
>> not demeaning the work you put into this.
certainly, go ahead!
> I went ahead and pushed this, since libvirt (at least) is clamoring to
> Absolutely.
>
> One idea would be:
>
> --gnulib-srcdir overrides environment, but defaults to $GNULIB_SRCDIR
>
> bootstrap require git, creates fresh clone
> bootstrap --gnulib-srcdir require git, clones using srcdir as
> reference
> bootstrap --no-git
> git IS used by the bootstrap script except for the one case where you
> specifically ask that it not be used. So, the best thing might be to
> enhance the bootstrap pre-requisite checks to see if --gnulib-srcdir is
> in effect and use that as a reason to skip the git prereq check.
That sounds s
>> I am using msys as build environment and git is not available there.
>
> From what I recall, git has been available on msys for some time.
> Have you looked at this?
>
> http://code.google.com/p/msysgit/
Yes I have, but they use a tweaked (patched) version of msys, so it
follows that it is not
Hello list,
Octave (http://www.octave.org) utilizes gnulib and a recent change in
gnulib breaks the build for MinGW platform, because gnulib now
enforces git to be available at bootstrap stage.
The change was introduced in a patch discussed in the following thread:
http://lists.gnu.org/archive/htm
11 matches
Mail list logo
