Re: building libpq.a static library

On 12 July 2017 at 23:46, Jeroen Ooms <jeroen(at)berkeley(dot)edu> wrote:

> On Wed, Jul 12, 2017 at 5:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Jeroen Ooms <jeroen(at)berkeley(dot)edu> writes:
> >> I maintain static libraries for libpq for the R programming language
> >> (we need static linking to ship with the binary packages).
> >
> > How do you get that past vendor packaging policies? When I worked at
> > Red Hat, there was a very strong policy against allowing any package
> > to statically embed parts of another one, because it creates serious
> > management problems if e.g. the other one needs a security update.
> > I'm sure Red Hat isn't the only distro that feels that way.
>
> We only use this on Windows. On platforms with a decent package
> manager we indeed link to a shared library.

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 .

On Mac OS X and Linux, you can use relative rpath linking. On OS X use
@executable_path either at link-time or later via install_name_tool . On
Linux, use $ORIGIN in your rpath. Beware of quoting issues with $ORIGIN
though.

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

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services