Greetings.

Today I went to build a new version of sqlite3.exe for Windows (using cygwin, which is my normal method), and it builds, but when I run the fresh built sqlite3.exe, it aborts promptly.

14:09:00.91>sqlite3
SQLite version 3.47.0 2024-10-08 17:27:00
Enter ".help" for usage hints.

14:12:16.78>

Since I had not built it in a while, I found out that the last check-in that I am able to build is f0c5a86f. The next version (0b83e8f1), although it completes ok, the executable aborts without error. I don't know what happened, so any help would be greatly appreciated. I build the sqlite3.exe for Windows using cygwin, and this command:

./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_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c

Let me know if you need anything to get this fixed. By the way, the latest trunk check-in (6364a2f0) also has the problem.

It does build the cygwin sqlite3 tool correctly:

$ sqlite3
-- Loading resources from /home/E608313/.sqliterc
SQLite version 3.47.0 2024-10-08 17:27:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>

Thanks for the support.

I found out that the last check-in that I am able to build is f0c5a86f. The next version (0b83e8f1), although it completes ok, the executable aborts without error.

0b83e8f1 doesn't make any sense as the breaking point because it modified only one of the Emscripten-specific files by adding an #if 0 block, so there's literally zero code difference for your case between those versions. My suspicion is that if you do a "make clean" between each of your builds to ensure that you haven't gotten any mis-built files, a different culprit will appear.

It does build the cygwin sqlite3 tool correctly:

Are you saying that cross-compilation from cygwin to Windows is what's failing but cygwin-for-cygwin is working?

Hi Stephan.

Are you saying that cross-compilation from cygwin to Windows is what's failing but cygwin-for-cygwin is working?

Correct. The cygwin build works great. The cross-compilation from cygwin to Windows fails. I even tried the command by-itself:

 x86_64-w64-mingw32-gcc -DSQLITE_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c

I wish there was an error or something.

The cygwin build works great. The cross-compilation from cygwin to Windows fails.

There's no way for me to reproduce this (for lack of the OS) but i can say, with 100% confidence, that the culprit checkin you have identified (0b83e8f1) cannot possibly be the culprit because it has literally zero effect on any build (it's just a single #if 0'd-out block of code (which has since been removed altogether, along with the rest of the long double bits)). If you can identify the checkin in which the cross-compilation misbehavior first appeared, we can possibly get it resolved before the 3.47 release.

... i can say, with 100% confidence, that the culprit checkin you have identified (0b83e8f1) cannot possibly be the culprit ...

I didn't think so either, but that one failed. the previous one worked. (Or so, I think.) I am trying to find out where the problem lies with a different computer (win11).

I didn't think so either, but that one failed. the previous one worked.

i recommend doing "make clean" between the builds, if you aren't already. If that still exhibits the misbehavior, you can get an even cleaner rebuild with:

$ fossil clean -x # will wipe out ALL files which are not an SCM-tracked part of that checkout
# If you aren't using fossil then instead do:
$ make distclean
$ ./configure ...
$ make

There's simply no way on earth that that particular checkin in affecting the build, so my suspicion is stale build artifacts being left over and confusing the results.

Sorry about the tardiness. Work and home stuff got in the way.

i recommend doing "make clean" between the builds, if you aren't already.

I do, only when I am going to repeat the configure script. However, the way that I cross-compile the SQLite tool is by following these steps:

- downloading the trunk tar.gz file (I.e. SQLite-da750e39.tar.gz)
- run 'tar xvf SQLite-da750e39.tar.gz'
- cd into the created folder (SQLite-da750e39)
- running './configure'
- then 'make install'
- then 'i686-w64-mingw32-gcc -shared -DFOR_WIN10 -DSQLITE_ENABLE_FTS5 -static-libgcc sqlite3.c -o sqlite3.dll' to create the sqlite3.dll for Windows 10/11
- then 'x86_64-w64-mingw32-gcc -DSQLITE_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c' to create a x64 sqlite3.exe for Windows 10/11

These steps have worked for a long time. I don't think this is missing of files versions problem. I repeat I think.

I just downloaded the latest trunk and I am getting this error after running 'make install':

 ... [clip] /home/E608313/b/sqlite/dbug/SQLite-da750e39/ext/userauth/sqlite3userauth.h /home/E608313/b/sqlite/dbug/SQLite-da750e39/ext/rbu/sqlite3rbu.h /home/E608313/b/sqlite/dbug/SQLite-da750e39/ext/rbu/sqlite3rbu.c /home/E608313/b/sqlite/dbug/SQLite-da750e39/ext/misc/stmt.c keywordhash.h opcodes.c opcodes.h parse.c parse.h sqlite_cfg.h shell.c sqlite3.h tsrc
rm tsrc/sqlite.h.in tsrc/parse.y
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-da750e39/tool/vdbe-compress.tcl  <tsrc/vdbe.c >vdbe.new
mv vdbe.new tsrc/vdbe.c
cp fts5.c fts5.h tsrc
touch .target_source
make: *** No rule to make target 'src-verify', needed by 'sqlite3.c'.  Stop.

E608313@HOR732978I ~/b/sqlite/dbug/SQLite-da750e39

I could provide more data, if you need it. Any idea why this happens?

I am still trying to find out the check-in that caused the problem. Thanks for the support.

make: *** No rule to make target 'src-verify', needed by 'sqlite3.c'. Stop.

This patch ought to fix that:

Index: Makefile.in
==================================================================
--- Makefile.in
+++ Makefile.in
@@ -844,11 +844,11 @@
 	$(TCLSH_CMD) $(TOP)/tool/vdbe-compress.tcl $(OPTS) <tsrc/vdbe.c >vdbe.new
 	mv vdbe.new tsrc/vdbe.c
 	cp fts5.c fts5.h tsrc
 	touch .target_source
 
-sqlite3.c:	.target_source $(TOP)/tool/mksqlite3c.tcl src-verify has_tclsh84
+sqlite3.c:	.target_source $(TOP)/tool/mksqlite3c.tcl src-verify$(BEXE) has_tclsh84
 	$(TCLSH_CMD) $(TOP)/tool/mksqlite3c.tcl $(AMALGAMATION_LINE_MACROS) $(EXTRA_SRC)
 	cp tsrc/sqlite3ext.h .
 	cp $(TOP)/ext/session/sqlite3session.h .
 
 sqlite3r.h: sqlite3.h has_tclsh84
@@ -1646,11 +1646,11 @@
 	rm -f *.dll *.lib *.exp *.def *.pc *.vsix *.so *.dylib pkgIndex.tcl
 	rm -f sqlite3_analyzer$(TEXE) sqlite3-rsync$(TEXE)
 	rm -f mptester$(TEXE) rbu$(TEXE)	srcck1$(TEXE)
 	rm -f fuzzershell$(TEXE) fuzzcheck$(TEXE) sqldiff$(TEXE) dbhash$(TEXE)
 	rm -f threadtest5$(TEXE)
-	rm -f src-verify has_tclsh*
+	rm -f src-verify$(BEXE) has_tclsh*
 
 # Removes build products and test logs.  Retains ./configure outputs.
 #
 clean:	tidy
 	rm -rf omittest* testrunner* testdir*

That will be checked in soon.

That will be checked in soon.

Thanks. So, I tried the latest check-in (8d7fe903), and there are a bunch of different errors now. At least now, there are errors. :-) I apologize for the long post, but I tried to take out some of the text not needed, IMO. Where you see a line containing [clip], there was data extracted.

E608313@HOR732978I ~/b/sqlite/dbug/SQLite-8d7fe903
$ ./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_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c && cp sqlite3.exe /cygdrive/c/P/bin/
checking build system type... x86_64-pc-cygwin
checking host system type... x86_64-pc-cygwin
checking for gcc... gcc
checking whether the C compiler works... yes
[clip]
checking whether to support RTREE... yes
checking whether to support SESSION... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sqlite3.pc
config.status: creating sqlite_cfg.h
config.status: executing libtool commands
sh /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/cktclsh.sh 8.4 tclsh8.6
touch has_tclsh84
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mkshellc.tcl >shell.c
gcc  -g -O2 -o mkkeywordhash.exe -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_PREUPDATE_HOOK   /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mkkeywordhash.c
./mkkeywordhash.exe >keywordhash.h
gcc  -g -O2 -o lemon.exe /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/lemon.c
cp /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/lempar.c .
cp /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/parse.y .
./lemon.exe -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_PREUPDATE_HOOK   -S parse.y
cat parse.h /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/vdbe.c | tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mkopcodeh.tcl >opcodes.h
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mkopcodec.tcl opcodes.h >opcodes.c
gcc  -g -O2 -o mksourceid.exe /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mksourceid.c
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/mksqlite3h.tcl /home/E608313/b/sqlite/dbug/SQLite-8d7fe903 >sqlite3.h
cp /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/ext/fts5/fts5parse.y .
rm -f fts5parse.h
./lemon.exe  -S fts5parse.y
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/ext/fts5/tool/mkfts5c.tcl
cp /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/ext/fts5/fts5.h .
rm -rf tsrc
mkdir tsrc
cp -f /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/alter.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/analyze.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/attach.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/auth.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/backup.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/bitvec.c /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/btmutex.c
[clip]
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
echo '#ifndef USE_SYSTEM_SQLITE' >tclsqlite3.c
cat sqlite3.c >>tclsqlite3.c
echo '#endif /* USE_SYSTEM_SQLITE */' >>tclsqlite3.c
cat /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/src/tclsqlite.c >>tclsqlite3.c
tclsh8.6 /home/E608313/b/sqlite/dbug/SQLite-8d7fe903/tool/buildtclext.tcl --cc "gcc" -g -O2 -DSQLITE_OS_WIN=1 -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_PREUPDATE_HOOK
generating pkgIndex.tcl...
gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xe4439): undefined reference to `Tcl_UnregisterChannel'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xe452a): undefined reference to `Tcl_Free'
[clip]
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xec8d6): undefined reference to `Tcl_CreateObjCommand'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xec937): undefined reference to `Tcl_CreateObjCommand'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xec960): undefined reference to `Tcl_CreateObjCommand'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cck9FnsH.o:tclsqlite3.c:(.text+0xec980): undefined reference to `Tcl_PkgProvideEx'
collect2: error: ld returned 1 exit status
make: *** [Makefile:1615: tclextension-install] Error 1

E608313@HOR732978I ~/b/sqlite/dbug/SQLite-8d7fe903
$

This was tried on two different cygwin systems (win10 & win11) with the same result.

win10
E608313@HOR732978I ~/b/sqlite/dbug/SQLite-8d7fe903
$ gcc --version
gcc (GCC) 11.5.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

E608313@HOR732978I ~/b/sqlite/dbug/SQLite-8d7fe903
$ tclsh
% puts $tcl_version
8.6
%

win11
jcabrera@jicman ~/b/sqlite/dbug/SQLite-8d7fe903
$ gcc --version
gcc (GCC) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jcabrera@jicman ~/b/sqlite/dbug/SQLite-8d7fe903
$ tclsh
%  puts $tcl_version
8.6
%

Should I not use the --enable-all option? It was working before. Thanks for the help.

undefined reference to `Tcl_UnregisterChannel'

There were recent changes to how tcl is discovered and applied which may have something to do with this.

The output looks okay to me up until the link errors. This is a guess, but can you run that again to the point where it fails, then re-run this part manually:

gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6

Adding:

gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/wherever/your/libtcl/is

:-?

Should I not use the --enable-all option?

That flag should be fine, and it works on all of the dev systems we've tested, but cygwin does not (AFAIK) belong to that particular set of environments.

gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/wherever/your/libtcl/is

Hmmm... I will have to figure this one out.

I don't know where the path for the tcl library is. So, I used the "--disable-tcl" configure option, i.e.,

 ./configure --enable-all --prefix=/usr --disable-tcl && make install

And that suppressed those errors and the cygwin build works:

jcabrera@jicman ~/b/sqlite/dbug/SQLite-9b4bc5c4
$ sqlite3
SQLite version 3.47.0 2024-10-15 14:28:23
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>

However, the cross compiled Windows built sqlite3.exe aborts:

14:18:21.09>sqlite3
SQLite version 3.47.0 2024-10-15 14:28:23
Enter ".help" for usage hints.

14:18:27.87>

By the way, I just found out that I can create a Windows 10/11 sqlite3.exe using i686-w64-mingw32-gcc (32b) version,

 i686-w64-mingw32-gcc -DSQLITE_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c

But when I run Dr. Hipp's test, it aborts in the Arabic string. However, the same test works on the cygwin version.

Sorry for the tardy reply.

gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/wherever/your/libtcl/is

So, what I did was to search for libtcl filenames,

$ find / -xdev -iname '*libtcl*'
/bin/libtcl8.6.dll
/lib/libtcl.dll.a
/lib/libtcl8.6.dll.a
/lib/libtclstub.a
/lib/libtclstub8.6.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/dde1.4/libtcldde14.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libtcl86.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libtclstub86.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/registry1.3/libtclregistry13.dll.a
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/dde1.4/libtcldde14.dll.a
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/libtcl86.dll.a
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/libtclstub86.a
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/reg1.3/libtclreg13.dll.a
/usr/bin/libtcl8.6.dll
/usr/lib/libtcl.dll.a
/usr/lib/libtcl8.6.dll.a
/usr/lib/libtclstub.a
/usr/lib/libtclstub8.6.a

and use these paths to run these commands (as per your suggestion):

gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/lib
gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/usr/lib/
gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib

Each of these manual commands resulted in the same errors previously reported:

E608313@HOR732978I ~/b/sqlite/SQLite-e904b37f
$ gcc -shared tclsqlite3.c -o libsqlite3.47.0.dll -Wl,-ltclstub8.6 -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccHziitD.o:tclsqlite3.c:(.text+0xe4439): undefined reference to `Tcl_UnregisterChannel'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccHziitD.o:tclsqlite3.c:(.text+0xe452a): undefined reference to `Tcl_Free'
[clip]
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccHziitD.o:tclsqlite3.c:(.text+0xec960): undefined reference to `Tcl_CreateObjCommand'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccHziitD.o:tclsqlite3.c:(.text+0xec980): undefined reference to `Tcl_PkgProvideEx'
collect2: error: ld returned 1 exit status

By the way, I also installed MSYS2, and the same thing happens. So, apparently the cygwin support has been damaged or discontinued. Maybe I am the only one using it. :-)

...i can say, with 100% confidence, that the culprit checkin you have identified (0b83e8f1) cannot possibly be the culprit...

You are correct. My apologies. I copied the wrong check-in. The culprit is the next one (f97f9944). It builds for cygwin ok, but for Windows, it appears to start, but then, it aborts right after:

10:42:13.19>sqlite3
SQLite version 3.47.0 2024-09-26 13:12:19 (UTF-16 console I/O)
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .q

10:42:22.39>sqlite3
SQLite version 3.47.0 2024-09-26 18:13:10 (UTF-16 console I/O)
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .q

11:05:03.88>sqlite3
SQLite version 3.47.0 2024-09-26 19:38:34
Enter ".help" for usage hints.
                                           <------------------ No SQLite prompt
11:15:15.53>                               <------------------ DOS Command prompt

So, Dr. Hipp added an enhancement to the CLI with the new ".www" dot-command. I know that after that one, although the sqlite3.exe builds ok for the cygwin system, the build for Win10/11 aborts after starting. This is the same build on cygwin:

E608313@HOR732978I ~/b/sqlite/dbug/SQLite-8d7fe903
$ sqlite3
-- Loading resources from /home/E608313/.sqliterc
SQLite version 3.47.0 2024-09-28 19:52:38
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>

Thoughts? Suggestions?

Please try the patch below. Let us know whether not it works.

Index: ext/misc/sqlite3_stdio.c
==================================================================
--- ext/misc/sqlite3_stdio.c
+++ ext/misc/sqlite3_stdio.c
@@ -11,11 +11,11 @@
 *************************************************************************
 **
 ** Implementation of standard I/O interfaces for UTF-8 that are missing
 ** on Windows.
 */
-#ifdef _WIN32  /* This file is a no-op on all platforms except Windows */
+#if defined(_WIN32) && !defined(__CYGWIN__)
 #ifndef _SQLITE3_STDIO_H_
 #include "sqlite3_stdio.h"
 #endif
 #undef WIN32_LEAN_AND_MEAN
 #define WIN32_LEAN_AND_MEAN

Index: ext/misc/sqlite3_stdio.h
==================================================================
--- ext/misc/sqlite3_stdio.h
+++ ext/misc/sqlite3_stdio.h
@@ -26,11 +26,11 @@
 ** also link in the accompanying sqlite3_stdio.c source file when compiling
 ** to get compatible interfaces.
 */
 #ifndef _SQLITE3_STDIO_H_
 #define _SQLITE3_STDIO_H_ 1
-#ifdef _WIN32
+#if defined(_WIN32) && !defined(__CYGWIN__)
 /**** Definitions For Windows ****/
 #include <stdio.h>
 #include <windows.h>

If the patch above compiles, then try running the following input through the resulting EXE file. Like this: "sqlite3 <multilang.txt" where the multilang.txt file is as follows. Confirm that none of the non-ASCII text gets garbled. Let us know how it goes, please.

.mode box
CREATE TABLE בראשית(
  vn INT,
  lang TEXT,
  words TEXT
);
INSERT INTO בראשית VALUES
  (1, 'en', 'In the beginning, God created the heavens and the earth'),
  (1, 'ru', 'В начале сотворил Бог небо и землю'),
  (1, 'he', 'בראשית ברא אלהים את השמים ואת הארץ'),
  (1, 'gr', 'ΕΝ ΑΡΧΗ ἐποίησεν ὁ θεὸς τὸν οὐρανὸν καὶ τὴν γῆν'),
  (1, 'th', 'ในเริ่มแรกนั้นพระเจ้าทรงเนรมิตสร้างฟ้าและแผ่นดินโลก'),
  (1, 'zh', '起初，神创造天地'),
  (1, 'ko', '태초에 하나님이 천지를 창조하시니라'),
  (1, 'ar', 'في البدء خلق الله السموات والارض');
SELECT * FROM בראשית;
CREATE VIEW v1 AS SELECT * FROM בראשית;

Please try the patch below. Let us know whether not it works.

I applied both patches to f97f9944. What follows was done after applying it and building:

jcabrera@jicman ~/b/sqlite/dbug/SQLite-f97f9944
$ patch -p0 < p1
patching file ext/misc/sqlite3_stdio.c
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ext/misc/sqlite3_stdio.c.rej

jcabrera@jicman ~/b/sqlite/dbug/SQLite-f97f9944
$ patch -p0 < p2
patching file ext/misc/sqlite3_stdio.h
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ext/misc/sqlite3_stdio.h.rej

But, it did not work:

15:17:55.23>sqlite3
SQLite version 3.47.0 2024-09-26 19:38:34
Enter ".help" for usage hints.

I will continue to use this post since it's the original cygwin configure problem.

Here is what I did:

• downloaded the latest check-in (5adc7d5d)
• untar'ed it ($ tar xf SQLite-5adc7d5d.tar.gz)
• cd to it (cd SQLite-5adc7d5d)
• ran this command:
• $ ./configure --enable-all --prefix=/usr && make install

and this is the output (partially):

E608313@HOR732978I ~/b/sqlite/SQLite-5adc7d5d
$ ./configure --enable-all --prefix=/usr && make install
Host System...x86_64-pc-cygwin
Build System...x86_64-pc-cygwin
C compiler... cc
C++ compiler... c++
Build C compiler...cc
Checking for stdlib.h...ok
srcdir = /home/E608313/b/sqlite/SQLite-5adc7d5d
top_srcdir = /home/E608313/b/sqlite/SQLite-5adc7d5d
Configuring SQLite version 3.48.0
Looking for install ... /usr/bin/install
Checking for sys/types.h...ok
Checking if -D_FILE_OFFSET_BITS=64 is needed...no
Checking for int8_t...ok
Checking for int16_t...ok
[...]
cc  -g -O2  -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_PREUPDATE_HOOK -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_THREADSAFE=1   -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I/usr/include -I. -I/home/E608313/b/sqlite/SQLite-5adc7d5d/src -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/rtree -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/icu  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/fts3 -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/session  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/misc  -shared -o libsqlite3.dll sqlite3.o -Wl,-rpath,/usr/lib      -lz
/usr/bin/install libsqlite3.dll "/usr/lib"
Setting up SO symlinks...
lrwxrwxrwx 1 E608313 Domain Users      16 Oct 31 10:11 libsqlite3.dll -> libsqlite3.dll.3
lrwxrwxrwx 1 E608313 Domain Users      21 Oct 31 10:11 libsqlite3.dll.3 -> libsqlite3.dll.3.48.0
-rwxr-xr-x 1 E608313 Domain Users 7440323 Oct 31 10:11 libsqlite3.dll.3.48.0
ar cr  libsqlite3.lib sqlite3.o
/usr/bin/install -m 0644 libsqlite3.lib "/usr/lib"
/usr/bin/install -m 0644 sqlite3.h "/home/E608313/b/sqlite/SQLite-5adc7d5d/src/sqlite3ext.h" "/usr/include"
. ./.tclenv.sh || exit $?; cc  -g -O2  -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_PREUPDATE_HOOK -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_THREADSAFE=1    -DUSE_TCL_STUBS=1 $TCL_INCLUDE_SPEC -I. -I/home/E608313/b/sqlite/SQLite-5adc7d5d/src -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/rtree -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/icu  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/fts3 -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/session  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/misc \
        -c /home/E608313/b/sqlite/SQLite-5adc7d5d/src/tclsqlite.c
. ./.tclenv.sh || exit $?; \
cc  -g -O2  -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_PREUPDATE_HOOK -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_THREADSAFE=1   -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I/usr/include -I. -I/home/E608313/b/sqlite/SQLite-5adc7d5d/src -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/rtree -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/icu  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/fts3 -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/session  -I/home/E608313/b/sqlite/SQLite-5adc7d5d/ext/misc  -shared -o libtclsqlite3.dll tclsqlite.o \
        $TCL_INCLUDE_SPEC $TCL_STUB_LIB_SPEC -Wl,-rpath,/usr/lib      -lz  \
        sqlite3.o -Wl,-rpath,$TCLLIBDIR
echo 'package ifneeded sqlite3 3.48.0 [list load [file join $dir libtclsqlite3[info sharedlibextension]] sqlite3]' > pkgIndex.tcl
. ./.tclenv.sh || exit $?; \
/usr/bin/install -d "$TCLLIBDIR"; \
/usr/bin/install libtclsqlite3.dll "$TCLLIBDIR"; \
/usr/bin/install -m 0644 pkgIndex.tcl "$TCLLIBDIR"
cc   sqlite3.o   -o sqlite3
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libcygwin.a(libcmain.o): in function `main':
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/lib/libcmain.c:37:(.text.startup+0x7b): undefined reference to `WinMain'
collect2: error: ld returned 1 exit status
make: *** [<builtin>: sqlite3] Error 1

This is different than before, but it's also a different build command. This is the one I was using before all the changes were done. Let me know if you want the whole configure output.

Like you, I followed the same steps as before to compile the check in you mention (5adc7d5d) using MAKEFILE and the process fails with the following errors:

jimsh0.c
.\autosetup\jimsh0.c(19289): error C2059: syntax error: '}'
.\autosetup\jimsh0.c(20182): error C2059: syntax error: '}'
.\autosetup\jimsh0.c(20391): error C2059: syntax error: '}'
NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\cl.EXE"' : return code '0x2'
Stop.

Hmmmm... you're using NMAKE. However, a few days ago, using the sqlite-trunk, I did get a jimsh0 error after trying to force a make:

$ make shell.c sqlite3.c
cc -g -o jimsh -DHAVE_REALPATH /home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c
C:/msys64/home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c: In function 'JimRealPath':
C:/msys64/home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c:4406:12: error: implicit declaration
 of function 'realpath' [-Wimplicit-function-declaration]
 4406 |     return realpath(path, resolved_path);
      |            ^~~~~~~~
C:/msys64/home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c:4406:12: error: returning 'int' from
 a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]
 4406 |     return realpath(path, resolved_path);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [/home/E608313/b/sqlite/sqlite-trunk/main.mk:378: jimsh] Error 1

But these are a bit different. I will keep inquiring...

I will keep inquiring...

Thanks.

This statement needs to be taken with a pinch of salt "Vanilla Windows builds are unaffected and we will continue to provide static makefiles for Windows." since I understood Vanilla to mean the existing process.

I did get a jimsh0 error after trying to force a make:

cc -g -o jimsh -DHAVE_REALPATH /home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c
...
C:/msys64/home/E608313/b/sqlite/sqlite-trunk/autosetup/jimsh0.c:4406:12: error: implicit declaration
 of function 'realpath' [-Wimplicit-function-declaration]
 4406 |     return realpath(path, resolved_path);

That suggests that the configure-time detection of readline() on that platform is producing a false positive. i will look into a stricter test for realpath(). Until then, this patch against the current trunk might work around the issue (depending on whether or not cygwin has Windows' _fullpath() API):

Index: auto.def
==================================================================
--- auto.def
+++ auto.def
@@ -670,16 +670,16 @@
       define BTCLSH "\$(TCLSH_CMD)"
     } else {
       # These headers are technically optional for JimTCL but necessary if
       # we want to use it for code generation:
       set sysh [cc-check-includes dirent.h sys/time.h]
-      if {$sysh && [cc-check-functions realpath]} {
-        define-append CFLAGS_JIMSH -DHAVE_REALPATH
-        define BTCLSH "\$(JIMSH)"
-      } elseif {$sysh && [cc-check-functions _fullpath]} {
+      if {$sysh && [cc-check-functions _fullpath]} {
         # _fullpath() is a Windows API
         define-append CFLAGS_JIMSH -DHAVE__FULLPATH
+        define BTCLSH "\$(JIMSH)"
+      } elseif {$sysh && [cc-check-functions realpath]} {
+        define-append CFLAGS_JIMSH -DHAVE_REALPATH
         define BTCLSH "\$(JIMSH)"
       } elseif {[file exists [get-define TCLSH_CMD]]} {
         set cgtcl [get-define TCLSH_CMD]
         define BTCLSH "\$(TCLSH_CMD)"
       } else {

All that does is swap the order of the checks, checking for _fullpath() before realpath().

If we cannot get realpath() or _fullpath() detected on Cygwin then Cygwin builds will require a tclsh installation, jimtcl is not sufficient for code generation purposes unless one of realpath/fullpath are available. If you already have a tclsh installed you can skip the above checks by using:

./configure --with-tclsh=/path/to/tclsh

which will force it to use that tclsh for all purposes, including code generation.

So, I found out that if I use this command,

$ ./configure --enable-all --prefix=/usr && make install

This is the result,

jcabrera@jicman ~/b/sqlite/SQLite-24aba7ee
$ ./configure --enable-all --prefix=/usr && make install
Host System...x86_64-pc-cygwin
Build System...x86_64-pc-cygwin
C compiler... cc
C++ compiler... c++
Build C compiler...cc
Checking for stdlib.h...ok
srcdir = /home/jcabrera/b/sqlite/SQLite-24aba7ee
top_srcdir = /home/jcabrera/b/sqlite/SQLite-24aba7ee
Configuring SQLite version 3.48.0
Looking for install ... /usr/bin/install
Checking for sys/types.h...ok
Checking if -D_FILE_OFFSET_BITS=64 is needed...no
Checking for int8_t...ok
Checking for int16_t...ok
[...]
cc  -g -O2  -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_PREUPDATE_HOOK -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_SESSION -DSQLITE_THREADSAFE=1   -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I/usr/include -I. -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/src -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/ext/rtree -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/ext/icu  -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/ext/fts3 -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/ext/session  -I/home/jcabrera/b/sqlite/SQLite-24aba7ee/ext/misc  -shared -o libtclsqlite3.dll tclsqlite.o \
        $TCL_INCLUDE_SPEC $TCL_STUB_LIB_SPEC -Wl,-rpath,/usr/lib      -lz  \
        sqlite3.o -Wl,-rpath,$TCLLIBDIR
echo 'package ifneeded sqlite3 3.48.0 [list load [file join $dir libtclsqlite3[info sharedlibextension]] sqlite3]' > pkgIndex.tcl
. ./.tclenv.sh || exit $?; \
/usr/bin/install -d "$TCLLIBDIR"; \
/usr/bin/install libtclsqlite3.dll "$TCLLIBDIR"; \
/usr/bin/install -m 0644 pkgIndex.tcl "$TCLLIBDIR"
cc   sqlite3.o   -o sqlite3
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../lib/libcygwin.a(libcmain.o): in function `main':
/usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/lib/libcmain.c:37:(.text.startup+0x79): undefined reference to `WinMain'
collect2: error: ld returned 1 exit status
make: *** [<builtin>: sqlite3] Error 1

But, if I use this command,

./configure --enable-all --prefix=/usr && make && make install

sqlite3 builds for cygwin. Note the extra make. That was not needed before. So, cygwin is all well with that extra make. I can also cross compile for Windows builds with this command:

$ i686-w64-mingw32-gcc -DSQLITE_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c

So, I was able to build both SQLite tools for both cygwin and Windows with 24aba7ee. I think the extra build did the trick.

But, if I use this command, ... make && make install

i believe that was just fixed in the current trunk. Please try from a clean tree without the extra "make".

Please try from a clean tree without the extra "make".

The latest check-in (af0a345b) has fixed both problems, and I am now a happy camper again. :-) I can now run this command:

$ ./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_ENABLE_FTS5 -DFOR_WIN10 shell.c -o sqlite3.exe sqlite3.c && cp sqlite3.exe /cygdrive/c/P/bin

and everything builds and completes as before. Thank you for all the support and hard work.

Compiling for Windows: I downloaded a1915cbd and I am still getting an error:

        cl -DHAVE__FULLPATH=1 .\autosetup\jimsh0.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30156 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

jimsh0.c
.\autosetup\jimsh0.c(19289): error C2059: syntax error: '}'
.\autosetup\jimsh0.c(20182): error C2059: syntax error: '}'
.\autosetup\jimsh0.c(20391): error C2059: syntax error: '}'
NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\cl.EXE"' : return code '0x2'
Stop.

It would be nice (isn't it time) to get this sorted.

It would be nice (isn't it time) to get this sorted.

Being snooty about it will not speed it up. We have a very small team and not all of us have Windows so cannot readily reproduce or fix this. Proposing a patch might help speed up the process.

Though i cannot confirm this because my compilers don't complain about it, it looks like removing the 3 offending lines and the single comma at the end of each previous line will do the trick for you.

Edit: or probably not. Those arrays require an empty entry, so the final entry of each needs to be {0,0,0,0,0,0}.

Though i cannot confirm this because my compilers don't complain about it,

Try adding -Wgnu-empty-initializer to the compilation flags. :-)

Try adding -Wgnu-empty-initializer to the compilation flags. :-)

Unfortunately, gcc 13.2 doesn't like that flag and clang 18.1 either silently ignores it or mistakenly fails to report it. However, enabling simply -W does the trick (plus a whole lot more!).

The process seems much slower ...

It likely is and that's almost certainly because the build now uses jimtcl for all of the code generation, which is somewhat slower than the canonical TCL. e.g. on this machine generation of sqlite3.c takes approx. 4.5s with jimtcl but 2.2s with the canonical tclsh. (It takes up to a minute on a Raspberry Pi4 running OpenBSD!)

Edit: when compiled with -O2 jimtcl speeds that up to 2.4s, but then jimsh itself takes much longer to compile (7.7s compared to 1.4s without -O2).

My suspicion is that if you were to edit the makefile so that it would use a canonical tclsh.exe, you would again see the build times you're used to. As the Windows-based makefiles are intended for "one-off" builds, not day-to-day development, any such change would probably be a waste of time, though - what you'd gain in build speed you'd lose in editing the makefile.

In the canonical build process we're seeing that the build takes approximately 2/3rds as long as v3.47, despite the time added by jimtcl, because we have lost the overhead libtool introduces.

I usually use the published pre-compiled binaries that are published except when significant enhancements are forthcoming in the next version i.e. one-off builds. As you say there is little point in editing the makefile.