Re: building libpq.a static library

On Thu, Jul 13, 2017 at 4:58 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> You shouldn't ever need static libraries on Windows, though. Because it
> searches the CWD first on its linker search path, you can just drop
> libpq.dll in the same directory as your binary/library and link to the stub
> libpq.lib .

This is not possible in our case. The R programming language binaries
are installed in the "program files" directory which is only writable
by the sys admin.

There are over 10.000 contributed packages (including one with
postgres drivers) which are installed by the user in the home dir and
the package DLL's need to get dynamically loaded at runtime. We have
been working with this system for a very long time and static linking
external libs to the package DLL is really the only reliable way to
prevent DLL problems across Windows versions/configurations

> I'm not trying to block support for a static libpq, I just don't see the
> point.

This is a bit overgeneralized, there are many use cases where static
linking is the only feasible way. Most libs support --enable static
and many distros ship both static and shared libs and leave it up to
user or developer author how to configure their application.