How to build SPM on Windows

I've been able to build the swift-package-manager project easily on macOS and Debian (WSL) by simply checking out a tag (e.g. swift-5.5-RELEASE) and running swift build. No such luck on Windows. It gets about 50 files in, and quits here:

D:\Swift\swift-package-manager\.build\checkouts\swift-llbuild\lib\Core\SQLiteBuildDB.cpp:28:10: fatal error: 'sqlite3.h' file not found
#include <sqlite3.h>
1 error generated.

I have sqlite3 installed on my system in using vcpkg. To find out where the headers are installed, I tried pkgconf --cflags sqlite3 which output:


So I tried:

 swift build -Xcc -IC:/dev/vcpkg/installed/x64-windows/include

As expected, this got to a point where it couldn't find the sqlite3 library. pkgconf --libs tells me:

-LC:/dev/vcpkg/installed/x64-windows/lib -lsqlite3

So I tried this:

swift build -Xcc -IC:/dev/vcpkg/installed/x64-windows/include -Xlinker -LC:/dev/vcpkg/installed/x64-windows/lib

And the build completes successfully. For it to actually run, I have to copy sqlite3.dll into the .build/debug directory. What changes would be necessary to make these flags unnecessary? Does SPM support discovering C flags and linker flags using pkgconf on Windows?

1 Like

I've written a batch script to install SQLite 3 through wget and unzip:

Set the version you want and its release year before you run it.

AFAIK the correct way for global package installation on Windows is to install DLLs into system search path, and install libs and headers into VC include path.

1 Like

This may be the Windows development culture, but it feels so wrong to install software like this. I like the way homebrew installs things. Honestly, with vcpkg, and a proper homebrew system Windows development could be a lot more sane.

I don't think that SPM should ever support pkg-config on Windows - it is not something that is normally used. nuget should be preferred over pkg-config.

It would be great to see someone implement nuget support for SPM. That would also improve things as we could pick up the correct paths into the cache via nuget and avoid this.

As to the DLLs, that just needs to be in the path and there is no way to change that behaviour. Path is the moral equivalent to LD_LIBRARY_PATH and DYLD_LIBRARY_PATH. There is no concept of rpath on Windows (which is technically a security issue on those platforms, as that can allow for code injection). CMake explicitly adds build and install rpaths for that reason.

Terms of Service

Privacy Policy

Cookie Policy