Copying the PostgreSQL DLL.

[AlastairGrowcott]

As part of the pqxx build it finds the PostgreSQL library and links to it. In our case, for a Windows build, it is correctly finding the import library to link to. The problem is that when we run the application it fails to start because it cannot find the DLL.

I could add a find_package(PostgreSQL REQUIRED) but having printed out all the CMake variables in your CMakeLists.txt, that is only finding the import library, no mention of the DLL. Also, putting that in my CMakeLists.txt, I may be paranoid but I am not certain that it will necessarily find the same package as your CMakeLists.txt finds. I also have a MinGW one and may, in future, have multiple PostgreSQL installs too.

I like that pqxx is a static library, but it means that I cannot use $<TARGET_RUNTIME_DLLS:pqxx>.

It would be nice if you CMakeLists.txt somehow found the DLL file and added it as a dependency. But I guess that is up to whatever magic finds the PostgreSQL package, and it doesn't seem to be setting any suitable variable. Do you have any ideas?

[jtv]

This is a bit out of my wheelhouse, to be honest. The CMake build lives largely thanks to contributors. I think it should be possible to build libpqxx as a shared library with the CMake build — you can with the autotools build.

One small detail for Windows that could be of help: I think that OS looks for shared libraries in the places listed in the PATH environment variable.

[tt4g]

After find_package(PostgreSQL REQUIRED), the CMake variable PostgreSQL_LIBRARIES is defined.
Print it using the message() function to verify the location of the libpq library recognized by CMake.
MinGW performs library detection independently of Windows.
Typically, the Windows OS cannot find this library.
If you are using MinGW's libpq library, copy the DLL to the same path as the executable file. This allows Windows to load the DLL.

[jtv]

Thanks @tt4g !

[AlastairGrowcott]

When I print PostgreSQL_LIBRARIES it only lists the libpq.lib file.

The problem I am having is finding the location of the libpq DLL. In this case I am using the Windows native installer for PostgreSQL. The MinGW case is easy to handle.

[jtv]

I guess when it's a problem of building libpqxx on Windows, all you really need should be the .lib accompanying the DLL. Libpqxx comes with a few binaries but you don't need those to actually run the library.

Perhaps we should try to provide a "no other binaries please" build.

[AlastairGrowcott]

I do need the libpq.dll to run the application that uses libpqxx. I know how to do the copy, the problem is A) locating the DLL that corresponds to the .lib, and B) associating it with libpqxx in a way that doesn't try to link the application to it directly. For some reason, if you set the dependency DLL in the IMPORTED_LINK_INTERFACE_LIBRARIES property for an import library it causes the build to try and link the application to that DLL which fails. I know this because I have a similar problem with a dependency library which is an import library that depends on a further DLL. I spent 6 hours trying to get that further DLL to be copied and in the end I gave up.

[AlastairGrowcott]

I would like to have an option to get libpqxx to link statically to libpq, and for my application to link statically to libpqxx, while at the same time using dynamic linking everywhere else.

[jtv]

That sounds like something you'd expect to be provided for in the tooling.

One dumb trick I sometimes use on more unixy systems is to make sure only the static library is in my link path when I link my application. That way I get dynamic libraries where possible, but I guarantee that this one library gets linked statically.

[tt4g]

@AlastairGrowcott Using static libraries avoids the need to search for linked libraries during build time, but pre-built libraries for many distributions are installed as shared libraries.
Recently, there are package managers that only provide static libraries, so you'll need to either install libraries on your system using them or build all necessary libraries as static libraries on your own machine using package build tools such as vcpkg, conan or scons.

[AlastairGrowcott]

For other OS I am happy to go with the package libraries. The problem is Windows which has no real convention on where to install stuff (such as PostgreSQL) and allows the user to freely override the install location. At build time the pqxx library searches for, and finds, libpq.lib. When I am building an installer for my application I want to make sure that I use the libpq.dll that exactly matches that libpq.lib.

With CMake I can specify that I prefer static linking, but that then applies to all dependencies, when I actually only want libpq and libpqxx statically linked.

I will see if that is possible.