Hi, I'm maintaining the mingw-w64-sqlite package for Arch Linux and am working through the 3.49.0 autosetup changes. I'm pretty close, but one thing I'm stuck on is getting the ".dll.a" files built. I see .dll and .lib(now .a in trunk) files, but no .dll.a files. Does anyone know how to build these with autosetup?

Here's a link to my WIP PKGBUILD file: https://gist.github.com/jazztickets/2ece64b61a64ac4b1d687c7741a55a1b

I'm pretty close, but one thing I'm stuck on is getting the ".dll.a" files built.

The build is not supposed to generate any ".dll.a" files. Your build "should" result in, among other things, a file named libsqlite3.dll. (More correctly: the build system is configured to use the extension ".dll" for shared libraries when run on a mingw environment, and we've yet to hear anyone who uses that environment claim that it should use a different extension.)

We have done literally zero testing or development in mingw and we do not officially support the various non-native Windows builds. i will aim to get a mingw environment installed soonish for testing, but (A) don't currently have any clue about what might cause mingw to not build the dll file and (B) can make no promises that (A) will change.

We do know that it builds fine in an msys2 "ucrt64" environment, but that's where our collective experience with msys/cygwin/mingw currently ends.

Here's a link to my WIP PKGBUILD file: https://gist.github.com/jazztickets/2ece64b61a64ac4b1d687c7741a55a1b

Nothing in that file sticks out to me as wrong¹, but if you will post the output of your build, from ./configure until the end, that will likely be helpful for tracking down any weirdness. If the log is huge, you can alternately post a link to it or email it to me at stephan at this domain.

1. ^{^} My apologies about the broken out-of-tree build for that particular bundle. You'll be able to remove that hack as of the next release, or earlier if you're willing to locally replace a few of the build files with copies from the 3.49 branch, as detailed in /forumpost/bffb546c5531da7.

For MinGW, ... and the import library .dll.a.

That's one of those mysterious platform-isms which requires a platform-specific solution.

If you can propose a "hook" which we can put in place for that purpose/similar purposes, e.g. a makefile var which is normally undefined but can be specifically passed in for this purpose, we can find a way to wedge it in there. If you would, after you get it working, please post a diff of your Makefile.in and i will take a look at adding some mechanism or other for that (either via the configure script or the makefile - not yet sure which).

After a bit of research I think all I need to do is append " -Wl,--out-implib,libsqlite3.dll.a" ...

Actually... it's now easier than that. In the current trunk and 3.49 branch, the configure script checks for support of that flag. If it's supported, that's automatically added to the flags for libsqlite3.so/dll. Apparently it's even supported on Linux Mint, though its true purpose still escapes me:

$ ./configure --all
...
Checking whether the C compiler accepts -Wl,--out-implib,libsqlite3.so.a...yes
...
$ make
...
$ ls -la libsqlite3.so*
-rwxrwxr-x 1 stephan stephan 3282504 Feb  9 05:33 libsqlite3.so
-rwxrwxr-x 1 stephan stephan 1801984 Feb  9 05:33 libsqlite3.so.a

(Sidebar: this is a great example of how we benefit from switching build environments. Making this change is not only trivial, but we can understand how it works, whereas the autotools were big black hole to us.)

Oh very nice! Although at this point I'm not sure how to go about building the trunk/3.49 branch. I'm normally using the sqlite-autoconf-XXX.tar.gz build from the downloads page. If I download the tarball from the fossil page and drop the files in I get these compile errors. It's okay though, I can always wait and just test 3.49.1.

Actually... it's now easier than that. In the current trunk and 3.49 branch, the configure script checks for support of that flag. If it's supported, that's automatically added to the flags for libsqlite3.so/dll.

@jazztickets my apologies, but it turns out that on some platforms the feature check for --out-implib says it's supported but then it fails at link-time, so this capability now requires explicit opt-in. As of the next release (3.50.0 or 3.49.1) you can use the new --opt-implib configure flag to enable this.