Thanks for introducing the new option.

I tested one of the snapshots. The import library is generated but not installed. Instead I get /bin/sh: line 1: [: missing]'` in the install logs:

~/mingw-w64-sqlite/src/sqlite-snapshot-202502212246/build-x86_64-w64-mingw32 ~/mingw-w64-sqlite/src/sqlite-snapshot-202502212246
+ /usr/bin/install -d /build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/lib
+ /usr/bin/install -d /build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/bin
+ /usr/bin/install -d /build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/include
+ /usr/bin/install -d /build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/lib/pkgconfig
+ /usr/bin/install -d /build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/share/man/man1
/usr/bin/install -m 0644 libsqlite3.a "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/lib"
/usr/bin/install sqlite3.exe "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/bin"
/usr/bin/install -m 0644 /build/mingw-w64-sqlite/src/sqlite-snapshot-202502212246/sqlite3.h /build/mingw-w64-sqlite/src/sqlite-snapshot-202502212246/sqlite3ext.h "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/include"
/usr/bin/install -m 0644 sqlite3.pc "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/lib/pkgconfig"
/usr/bin/install -m 0644 /build/mingw-w64-sqlite/src/sqlite-snapshot-202502212246/sqlite3.1 "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/share/man/man1"
/bin/sh: line 1: [: missing `]'
/usr/bin/install libsqlite3-0.dll "/build/mingw-w64-sqlite/pkg/mingw-w64-sqlite/usr/x86_64-w64-mingw32/bin"
~/mingw-w64-sqlite/src/sqlite-snapshot-202502212246

The DLL itself is installed correctly under the expected name as shown in these logs.

I installed the import library manually for now and tested the x86_64 build which seems to work. (The executable links against libsqlite3-0.dll.)

The import library is generated but not installed. Instead I get /bin/sh: line 1:

That was coincidentally fixed about 2 minutes ago, and a new snapshot has been uploaded.

The DLL itself is installed correctly under the expected name as shown in these logs.

Great, thank you.

x86_64-w64-mingw32

Can you please point me to a page showing how to set up a similar environment? i have yet to get a mingw environment working, only msys2 and cygwin.

Thank you for testing!

I tested snapshot 202502212343 but it didn't fix the installation issue. The install logs look the same (except for the snapshot number).

Can you please point me to a page showing how to set up a similar environment? i have yet to get a mingw environment working, only msys2 and cygwin.

On an Arch Linux system one can simply install a few packages (mentioned on the Arch Wiki) to get started. Of course one can use containers to make use of this packaging on other distributions as well.

On other distributions there also exist similar packaging but I would also have to look that up.

On Windows one can simply install MSYS2 and install the mingw-w64 packages from their repositories. Considering you already have MSYS2 this is probably the easiest option for you. (Note that MSYS2 also provides cygwin-based packaging. Those packages are simply called like their Arch Linux equivalent, e.g. openssh. I am talking about the mingw-w64-based packages here, though. Those exist in multiple variants and are called e.g. mingw-w64-ucrt-x86_64-openssh.)

I tested snapshot 202502212343 but it didn't fix the installation issue.

Apologies, i was working from 3 different copies of the tree and build the snapshot from the wrong one. Snapshot 202502220001 is now online and is what the previous snapshot should have been.

On Windows one can simply install MSYS2 and install the mingw-w64 packages from their repositories.

Thank you, i'll look at that approach. That sounds like the most straightforward, though doing it on Alpine is also interesting, as i've got an Alpine VM handy. (Edit: oh, you said Arch, not Alpine! Oh, well.)

I can confirm that snapshot 202502220001 works.

--disable-tcl

Apologies, i was building from the canonical tree at the time, not the (generated) autoconf one, and the latter doesn't need/support that flag. Simply remove that flag and it should build. My post has been updated to remove that flag.

Cross compile failed using toolchain x86_64-w64-mingw32: https://github.com/musl-cross/musl-cross

Full log: https://github.com/abcfy2/aria2-static-build/actions/runs/13468116983/job/37637802353

$ ./configure --build="x86_64-pc-linux-gnu" --host="x86_64-w64-mingw32" --prefix="${CROSS_PREFIX}" --enable-static --disable-shared --disable-load-extension
'/cross_root/x86_64-w64-mingw32/lib/libsqlite3.a' -> 'libsqlite3.lib'
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /cross_root/x86_64-w64-mingw32/bin/ld
checking if the linker (/cross_root/x86_64-w64-mingw32/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /cross_root/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/cross_root/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3145728
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /cross_root/x86_64-w64-mingw32/bin/ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking command to parse /cross_root/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/cross_root/x86_64-w64-mingw32/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for int8_t... yes
checking for int16_t... yes
checking for int32_t... yes
checking for int64_t... yes
checking for intptr_t... yes
checking for uint8_t... yes
checking for uint16_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking for uintptr_t... yes
checking for sys/types.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for stdint.h... (cached) yes
checking for inttypes.h... (cached) yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for fdatasync... no
checking for gmtime_r... no
checking for isnan... yes
checking for localtime_r... no
checking for localtime_s... no
checking for malloc_usable_size... no
checking for strchrnul... no
checking for usleep... yes
checking for utime... yes
checking for pread... no
checking for pread64... no
checking for pwrite... no
checking for pwrite64... no
checking for tclsh8.7... no
checking for tclsh8.6... tclsh8.6
configure: Version set to 3.44
configure: Release set to 3.44.4
checking for WASI SDK directory... no
checking for gcc... gcc
checking whether to support threadsafe operation... yes
checking for library containing pthread_create... none required
checking for library containing pthread_mutexattr_init... none required
checking whether to support shared library linked as release mode or not... no
checking whether to use an in-ram database for temporary tables... no
checking if executables have the .exe suffix... unknown
configure: WARNING: Can't find Tcl configuration definitions
configure: WARNING: *** Without Tcl the regression tests cannot be executed ***
configure: WARNING: *** Consider using --with-tcl=... to define location of Tcl ***
checking for Tcl configuration... checking for library containing readline... no
checking for library containing tgetent... no
checking for readline in -lreadline... no
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
not using linenoise
checking for library containing fdatasync... no
checking build type... release
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for library containing deflate... -lz
checking whether to support math functions... yes
checking for library containing ceil... none required
checking whether to support JSON functions... yes
checking whether to support MEMSYS5... no
checking whether to support MEMSYS3... no
checking whether to support FTS3... no
checking whether to support FTS4... no
checking whether to support FTS5... no
checking whether to support LIMIT on UPDATE and DELETE statements... no
checking whether to support GEOPOLY... no
checking whether to support RTREE... no
checking whether to support SESSION... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sqlite3.pc
config.status: creating sqlite_cfg.h
config.status: executing libtool commands

# make
gcc  -g -o mksourceid.exe /usr/src/sqlite-3.49.1/tool/mksourceid.c
sh /usr/src/sqlite-3.49.1/tool/cktclsh.sh 8.4 tclsh8.6
touch has_tclsh84
gcc  -g -o mkkeywordhash.exe -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_ENABLE_MATH_FUNCTIONS  /usr/src/sqlite-3.49.1/tool/mkkeywordhash.c
gcc  -g -o lemon.exe /usr/src/sqlite-3.49.1/tool/lemon.c
tclsh8.6 /usr/src/sqlite-3.49.1/tool/mkshellc.tcl >shell.c
./mkkeywordhash.exe >keywordhash.h
gcc  -g -o src-verify.exe /usr/src/sqlite-3.49.1/tool/src-verify.c
tclsh8.6 /usr/src/sqlite-3.49.1/tool/mksqlite3h.tcl /usr/src/sqlite-3.49.1 >sqlite3.h
couldn't execute "/usr/src/sqlite-3.49.1/mksourceid": no such file or directory
    while executing
"exec $PWD/mksourceid manifest"
    invoked from within
"set zSourceId [exec $PWD/mksourceid manifest]"
    (file "/usr/src/sqlite-3.49.1/tool/mksqlite3h.tcl" line 65)
make: *** [Makefile:1123: sqlite3.h] Error 1
make: *** Waiting for unfinished jobs....
cp /usr/src/sqlite-3.49.1/tool/lempar.c .

couldn't execute "/usr/src/sqlite-3.49.1/mksourceid": no such file or directory
    while executing

That's happening because the mksqlite3h.tcl script calls mksourceid and does not know that it needs to add the .exe extension. That's arguably a bug in tcl or the OS, as users do not need to provide a .exe extension when invoking executables.

We'll get that fixed, but this applies only to the canonical source tree, not the "autoconf" bundle which approximately (based on downloads traffic) 85% of users use.

couldn't execute "/usr/src/sqlite-3.49.1/mksourceid": no such file or directory

That's now fixed in the current snapshot at https://wasm-testing.sqlite.org/tmp/ (timestamp=202502221458). Curiously, cygwin did not reproduce the problem for me but msys2 did.

Cross compile failed using toolchain x86_64-w64-mingw32: https://github.com/musl-cross/musl-cross ... Full log: https://github.com/abcfy2/aria2-static-build/actions/runs/13468116983/job/37637802353

Something is wrong with that log. It claims to be using 3.49.1 but it's using autoconf, which 3.49.1 does not use.

wget ...sqlite-3.49.1.tar.gz.part https://github.com/sqlite/sqlite/archive/release.tar.gz

That appears to be serving you the wrong thing. Firstly, it's 79mb, which is way too large, and secondly the output is definitely not from 3.49.x.

Ah. Am I wrong? I thought the release branch would always point to the latest release version. So what does release branch do ?

So what does release branch do ?

Ah, here's what happened: version 3.44.4 was recently tagged on behalf of a customer. That version is what the "release" tag currently resolves to, as can currently be seen at https://sqlite.org/src/info/release.

Presumably that's what github is serving you. We don't use github except to update the github mirror from the canonical tree.

Ah. Got it. My script always build from the latest sqlite version. So I thought this URL is simple, I just use https://github.com/sqlite/sqlite/archive/release.tar.gz to get the latest release.

Now it seems that I need to adjust the script to grab the download link on https://sqlite.org/download.html to get the latest release version.

Thank you.

libsqlite3.dll is installed correctly to $PREFIX/bin, but no import library (libsqlite3.a) is installed at all.

The import library is only built if it's explicitly requested. Add --out-implib to your configure flags and you'll find libsqlite3.dll.a in your prefix/lib. (Edit: you already said that, didn't you? That's what i get for not reading until the end before responding.)

We don't implicitly enable the import lib, even if the platform claims to support it, because it's supported on all(?) Linux environments but none of them need it. Only a tiny, tiny fraction of systems (the Windows-hosted Unix-like environments) need it and on all other platforms it's useless noise.

That said, i will look into auto-enabling it on these outlier systems, with the caveat that experience suggests that as soon as we do that, someone is going not want it for reasons of their own, then we'll be asked to add a way to opt out. For the time being, it requires opt-in.

That said, i will look into auto-enabling it on these outlier systems, with the caveat that experience suggests that as soon as we do that, someone is going not want it for reasons of their own, then we'll be asked to add a way to opt out. For the time being, it requires opt-in.

That's now in the latest snapshot (timestamp=202502221733):

If --out-implib is not provided and the platform is one of (msys, cygwin, mingw) then --out-implib=auto is implied and a warning is emitted notifying the user of that. --out-implib=none can be used to explicitly disable that special treatment.

Similarly, if --dll-basename is not provided and the platform is one of the above, then --dll-basename=auto is implied and a warning is emitted notifying the user of that. --dll-basename=default can be used to explicitly disable that special treatment.

(Edit: update snapshot timestamp and replace dll-basename=none with the more sensible dll-basename=default)

This post is specifically addressed to those of you who either maintain packages for, or who frequently use, any of the Unix-like environments for Windows, e.g. msys2, cygwin, mingw1, and whatever else the cool kids are using these days.

A new question for folks on such platforms:

Should use of the -rpath linker flag be disabled on those builds?

The current handling of rpath does not line up with how the libraries are built: the libs go in prefix/bin but the rpath is prefix/lib.

This post is specifically addressed to those of you who either maintain packages for, or who frequently use, any of the Unix-like environments for Windows, e.g. msys2, cygwin, mingw, and whatever else the cool kids are using these days.

Forewarning to all such folks: the branch in which this thread's features have been developed will be merged into the trunk on 2025-02-25 unless we receive feedback about it being Completely Wrong for one of those environments. If you have opinions or suggestions left to voice on these changes, please do so sooner rather than later.

Thank you all for your feedback so far! AFAIK all of your points have been addressed but i am open to contradicting views on that.

If you have opinions or suggestions left to voice on these changes, please do so sooner rather than later.

So sorry, Stephan. I've been discombobulated with a huge project and new software to learn and train. I will test it some time today.

I will test it some time today.

That would be great, thank you. The biggest changes are in how the DLL is named and installed. They're unusual but seem to be what the package maintainers want.

A new snapshot is now online for the current trunk, with timestamp=202502261922.

Can I also get it from here: https://sqlite.org/src/tarball/trunk/sqlite-trunk.tar.gz

Can I also get it from here...

Absolutely. That's the full/canonical build. The snapshots are the preprocessed "autoconf" variant (which is what accounts for approximately 85% of source code downloads, last i checked).

I downloaded the truck, as of this morning,

13:17:23.32>sqlite3
SQLite version 3.50.0 2025-02-27 16:07:49
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .ver
SQLite 3.50.0 2025-02-27 16:07:49 3f57584710d611748eb0af797c58c72e4ac099db09f5286cafdbd9a8ce354c90
gcc-12.4.0 (64-bit)
sqlite> sqlite>

and all is fine. :-) Well, ..., the only thing is that I get a double prompt for the cross compiled sqlite3.exe tool in Windows for both msys and cygwin. This happened a few versions back, but it was fixed. Now, it's back. That is all.

and all is fine. :-)

Great, thank you!

Well, ..., the only thing is that I get a double prompt for the cross compiled sqlite3.exe tool in Windows for both msys and cygwin.

i'm not seeing any double-prompts on any of cygwin or msys2 (plain msys, mingw32, mingw64) but am, on mingw32 (only), seeing something similar:

select 1;<tap ENTER>1

instead of:

select 1;<tap ENTER>
1

That's unrelated to the build process, though, so i have not yet looked into it. It's either an issue with the underlying environment's libraries or feature selection/activation in the C code (e.g. incorrect #ifdef checks for that particular environment).

This happened a few versions back, but it was fixed. Now, it's back.

i'll look into those, thank you for the links.