Was this an intentional change?

The current behavior is intentional. That it's a change is new information¹.

Before version 3.49 the name of the library was libsqlite3-0.dll. As of 3.49 the name of the library is libsqlite3.dll.

This type of ever-recurring oddity is why we do not actively/officially support any Windows builds except for "native" ones.

The source files included in SQLite's "autoconf" and "amalgamation" source distributions are trivial enough to build that creating environment-specific makefiles should pose no particular challenge to folks who have environment-specific needs.

What's not trivial is accounting for every potential environment's expectations in our makefiles, so we rely on interested users/communities (like package repositories) which have custom needs to account for those needs themselves. Case in point:

If we look at how the package-repo-installed copies of sqlite are installed globally² in various non-native Windows environments, noting that this is literally first time i've ever looked at these:

• cygwin installs cygsqlite3-0.dll
• msys2 installs msys-sqlite3-0.dll
• Your environment wants libsqlite3-0.dll

As you've demonstrated, we've gone some 4 months without ever having had to recognize that a -0 suffix³ is expected in those environments, for the very simple reason that we do not install/use sqlite this way and are ignorant of the platform-isms involved. Ideally, we would very much like to remain so (🙉🙈🙊) and leave those details to folks well-versed in them (in this case, platform-level package maintainers).

We make every effort to ensure that the configure/make process works on every platform we can test it on, but installation of the resulting DLL has proven to be the most platform-variable and opinionated aspect of the overall build process.

For additional context, this is how I build SQLite for Windows

Certainly any platform-specific renaming of the target DLL file can be done as part of that build script, right alongside the lines which move the DLL around?

Sidebar: that wouldn't work in conjunction with the --disable-static-shell flag, as the resulting DLL name would not match the name the shell was built against unless perhaps those environments' library loaders perform some voodoo to automatically account for the numeric suffix. Such a use case falls neatly into the category of "custom needs, custom solutions."

1. ^{^} Noting that we don't use such environments in our daily lives, so are not well-versed in their platform-isms.
2. ^{^} As distinct from how our build files do it.
3. ^{^} No, the ABI has not changed, nor will it for the lifetime of version 3.x.

Thanks for the quick answer.

TLDR: I take it that the -0 suffix was never an intended behaviour of the build system and libsqlite3.dll is the canonical library name intended by upstream when targeting Windows. That means I will simply rebuild everything to use that "new" library name. I actually want to package things in-line with upstream despite my different build environment/tooling (and hence asked this question here).

What's not trivial is accounting for every potential environment's expectations in our makefiles, so we rely on interested users/communities (like package repositories) which have custom needs to account for those needs themselves.

I am one of the "interested users". I provide an Arch Linux repository with many packages (including SQLite) to allow cross compiling on Arch Linux for Windows. I just like to note that we (me or the concrete maintainer of the SQLite package) do not have much "custom needs". We mainly rely on upstream not breaking cross compilation or compilation for Windows in general. We did never append the -0 suffix explicitly and I personally also don't think that would be a good idea as it would mean to needlessly digress from upstream defaults. However, before 3.49 the -0 was the upstream default in some sense. At least I perceived it that way because when invoking the build script it simply produced such binaries.

… without ever having had to recognize that a -0 suffix3 is expected in those environments …

My only expectation is that the library name stays the same (unless there actually is an ABI break).

As you've demonstrated, we've gone some 4 months without ever having had to recognize that a -0 suffix3 is expected in those environments, …

I take it now that you were not aware that the old build system behaved that way (that it was adding the -0 suffix in certain environments).

… noting that this is literally first time i've ever looked at these

Note that this is also the first time I had to deal with SQLite's build system specifically. I think both of our statements actually speak for the quality of SQLite's build system in general - it just works in different envs without having to care much about it :-)

The current behaviour is intentional. That it's a change is new information1.

I only saw that the build system was changed but nothing in particular about the library name. However, I have now read your writeup on sonames and it seems somewhat related. The build system you were previously using was trying to "emulate" sonames for Windows builds by appending the -0 suffix and this simply seems to be no longer the case with the new build system. Of course the solution to use a symlink (mentioned in your writeup) is not really applicable for Windows. However, I can simply rebuild everything so that is also not really required.

This type of ever-recurring oddity is why we do not actively/officially support any Windows builds except for "native" ones.

Note that builds using GCC/Clang/mingw-w64 produce "native" binaries. (You were probably also not saying the opposite. I just added this statement for clarification.)

Certainly any platform-specific renaming of the target DLL file can be done as part of that build script, right alongside the lines which move the DLL around?

Yes, it can. But it would not just be moving the DLL file around. One would also have to patch the import library (the .dll.a file by mingw-w64 conventions) to refer to the library under its old name. Otherwise, when linking against SQLite using the import library (and that is how linking is generally done, even though in MSVC environments the import libraries have the .lib suffix) the linker will still produce a binary that links against the new library name.

TLDR: I take it that the -0 suffix was never an intended behaviour of the build system and libsqlite3.dll is the canonical library name intended by upstream when targeting Windows.

An excellent summary, yes.

libtool performed a lot of platform-specific installation-time voodoo we were entirely unaware of, like stamping Mac-specific version numbers on libraries (who knew?). On the one hand, "great, it took care of that!" and on the other we collectively have an allergy against voodoo in our code the build process and are keen to take back control of our builds. We knew going in to this port that libtool took care of certain things, but were completely unaware that some of these other things even existed (like renaming the dll to cygfoo-N.dll (who knew?)).

We mainly rely on upstream not breaking cross compilation or compilation for Windows in general.

We don't intentionally break it, but we also do not actively target or support Windows builds beyond the MSVC-driven one, as we don't use those environments (so can't meaningfully claim to maintain them properly) and they've proven to be a significant maintenance sink for us.

As this project's current "Build Guy" i'm super-duper-keen on keeping the configure/make steps working on all feasible platforms, whether cross-compiling or not. It's the installation rules where the variability skyrockets and my devotion to the cause admittedly falters.

We did never append the -0 suffix explicitly and I personally also don't think that would be a good idea as it would mean to needlessly digress from upstream defaults. However, before 3.49 the -0 was the upstream default in some sense. At least I perceived it that way because when invoking the build script it simply produced such binaries.

i'm torn on that point. On the one hand, we want to reduce downstream disruption. On the other, we've no intention of remaining complete autotools/libtool-compatible, in particular on platforms we don't actively target. One potential approach to resolving this is covered below.

My only expectation is that the library name stays the same (unless there actually is an ABI break).

Agreed entirely, but i also believe that that largely falls into the "installation rules" category of problems. (But see below.)

The build system you were previously using was trying to "emulate" sonames for Windows builds by appending the -0 suffix ...

That had not occurred to me but sounds very likely.

Note that builds using GCC/Clang/mingw-w64 produce "native" binaries. (You were probably also not saying the opposite. I just added this statement for clarification.)

Indeed, our colloquial usage of "native" on Windows refers not to the resulting binaries but specifically means "Microsoft's build tools."

One would also have to patch the import library (the .dll.a file by mingw-w64 conventions) to refer to the library under its old name. Otherwise, when linking against SQLite using the import library (and that is how linking is generally done, even though in MSVC environments the import libraries have the .lib suffix) the linker will still produce a binary that links against the new library name.

Fair point. A similar problem exists when using the --disable-static-shell flag, which links the CLI shell app against the DLL instead of directly embedding a copy of sqlite3.c.

i'm tossing around ideas for how we might enable users to define the library name via the config process and/or override it by passing a var to the makefile, but don't yet have a concrete solution to that. Abstractly, something like:

./configure --dll-name=msys-sqlite3-0 --out-implib

# or:

./configure --dll-name=auto # use a name conventional for the target platforms, if we know it.

Which would result in:

msys-sqlite3-0.dll
msys-sqlite3-0.dll.a

but whether or not that really makes sense is not yet clear - experimentation is pending. If you have ideas in that direction, or alternatives, i'm all ears.

Similarly, i need to experiment with approaches for encapsulating the installation rules into platform-specific chunks, as msys2, cygwin, mingw, Darwin, and presumably many more platforms all want to do their own things, and our current install rules organization doesn't scale well for that. We never really anticipated providing install rules for anything beyond "conventional Unix" environments (Linux, BSD, Solaris, etc.).

Thank you for your feedback and ideas!