Greetings!

The latest tarball (5e18ce68) is failing with this error on MSYS2:

U618346@HOR732978I MSYS ~/b/sqlite/SQLite-5e18ce68
$ ./configure --enable-all --prefix=/usr && make install && i686-w64-mingw32-gcc -shared -DFOR_WIN10 -DSQLITE_ENABLE_FTS5 -static-libgcc sqlite3.c -o sqlite3.dll && x86_64-w64-mingw32-gcc -DSQLITE_OS_WIN=1 -DSQLITE_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c && cp sqlite3.exe /c/P/bin/
Host System...x86_64-pc-msys
Build System...x86_64-pc-msys
C compiler... cc
C++ compiler... c++
Build C compiler...cc
Checking for stdlib.h...ok
Source dir = /home/U618346/b/sqlite/SQLite-5e18ce68
Build dir  = /home/U618346/b/sqlite/SQLite-5e18ce68
Configuring SQLite version 3.49.0
Looking for install ... /usr/bin/install
Checking for int8_t...ok
...
...
346/b/sqlite/SQLite-5e18ce68/ext/rtree/rtree.c /home/U618346/b/sqlite/SQLite-5e18ce68/ext/rtree/geopoly.c /home/U618346/b/sqlite/SQLite-5e18ce68/ext/session/sqlite3session.c /home/U618346/b/sqlite/SQLite-5e18ce68/ext/session/sqlite3session.h /home/U618346/b/sqlite/SQLite-5e18ce68/ext/rbu/sqlite3rbu.h /home/U618346/b/sqlite/SQLite-5e18ce68/ext/rbu/sqlite3rbu.c /home/U618346/b/sqlite/SQLite-5e18ce68/ext/misc/stmt.c keywordhash.h opcodes.c opcodes.h parse.c parse.h sqlite_cfg.h shell.c sqlite3.h tsrc
rm -f tsrc/sqlite.h.in tsrc/parse.y
./jimsh /home/U618346/b/sqlite/SQLite-5e18ce68/tool/vdbe-compress.tcl  <tsrc/vdbe.c >vdbe.new
mv -f vdbe.new tsrc/vdbe.c
cp fts5.c fts5.h tsrc
touch .target_source
./jimsh /home/U618346/b/sqlite/SQLite-5e18ce68/tool/mksqlite3c.tcl --linemacros=0
C:/msys64/home/U618346/b/sqlite/SQLite-5e18ce68/tool/mksqlite3c.tcl:92: Error: format string too lon
g or invalid time
Traceback (most recent call last):
  File "C:/msys64/home/U618346/b/sqlite/SQLite-5e18ce68/tool/mksqlite3c.tcl", line 92, in fconfigure
    clock format -1408 -format {%Y-%m-%d %H:%M:%S UTC} -gmt 1
make: *** [/home/U618346/b/sqlite/SQLite-5e18ce68/main.mk:1073: sqlite3.c] Error 1

U618346@HOR732978I MSYS ~/b/sqlite/SQLite-5e18ce68

I can build the previous check-in (a7ecb2f4b7eee78b) without an error. Thoughts? Thanks.

josé

clock format -1408 -format {%Y-%m-%d %H:%M:%S UTC}

This has come up twice now and there's something wonky with the affected environments. Both reports include negative time values. According to the other report, removing the trailing " UTC" from the time string resolves the error but it does not explain why that environment is reporting completely wrong timestamps (negative values).

It's currently anyone's guess as to what precisely is causing this.

By the way, I just did a 'make clean' on same check-in that failed previously, re-ran the same build command, and it built without an error. So, it appears as if it's some specific time. Or, perhaps a bug in the time libraries of the environment where the failures are happening.

By the way, I just did a 'make clean' on same check-in that failed previously, re-ran the same build command, and it built without an error.

We don't know where this particular failure is coming from. i've investigated JimTCL to see if it's doing anything which looks relevant on (only) Windows but its "clock seconds" implementation is a single-line wrapper around this trivial core implementation:

jim_wide Jim_GetTimeUsec(unsigned type)
{
    long long now;
    struct timeval tv;
#if defined(HAVE_CLOCK_GETTIME)
    struct timespec ts;

    if (clock_gettime(type, &ts) == 0) {
        now = ts.tv_sec * 1000000LL + ts.tv_nsec / 1000;
    }
    else
#endif
    {
        gettimeofday(&tv, NULL);
        now = tv.tv_sec * 1000000LL + tv.tv_usec;
    }
    return now;
}

Noting that the jim_wide type is long long and, if i'm reading this right, JimTCL hard-codes the HAVE_LONG_LONG feature flag into Windows builds, so this does not seem to be a case of it using too small of an integer type.

A computer with Windows miraculously appeared on my doorstep this past weekend and i will be looking into this specific failure as soon as i can figure out how to operate that computer, but all existing evidence currently points to this being a bug "somewhere" in the msys2 toolchain.

Sidebar: the error about the clock formatting buffer possibly being too small is a proverbial red herring - that buffer is 100 bytes long. The real issue is the platform tripping over that inexplicable timestamp.

i will be looking into this specific failure as soon as i can figure out how to operate that computer, but all existing evidence currently points to this being a bug "somewhere" in the msys2 toolchain.

FWIW, this oddity does not reproduce for me using msys2's "ucrt64" environment:

./jimsh /home/U618346/b/sqlite/SQLite-5e18ce68/tool/mksqlite3c.tcl --linemacros=0 C:/msys64/home/U618346/b/sqlite/SQLite-5e18ce68/tool/mksqlite3c.tcl:92: Error: format string too long or invalid time

In addition to testing it via the build process, i've tested jimsh in isolation and its "clock seconds" command works as expected every time. Why on earth it returns negative values in some msys environments is a mystery, but we've no reason to believe that the fault is in jimsh. Its clock command is only a paper-thin wrapper around the environment-provided time-handling APIs, and all indications are that some as-yet-unknown "something" in msys is misbehaving.

Thanks for the fine explanation, Stephan. Maybe I should switch to ucrt64 environment.

Answers:

• #1. It was not 1969-12-31 23:36:32 at the time of the run, but there could be a library that is messed up somewhere.

• #2. No problem. I understand. by the way, the next check-in built without any problem.

I thank you for your wonderful gifts to the computer world.