Hi,
Splitting out to a new thread. Started at
https://www.postgresql.org/message-id/20220915051754.ccx35szetbvnjv7g%40awork3.anarazel.de
On 2022-09-14 22:17:54 -0700, Andres Freund wrote:
> On 2022-09-15 01:10:16 -0400, Tom Lane wrote:
> > I realize that there are people for whom other considerations outweigh
> > that, but I don't think that we should install static libraries by
> > default. Long ago it was pretty common for configure scripts to
> > offer --enable-shared and --enable-static options ... should we
> > resurrect that?
>
> It'd be easy enough. I don't really have an opinion on whether it's worth
> having the options. I think most packaging systems have ways of not including
> files even if $software installs them.
A few questions, in case we want to do this:
1) should this affect libraries we build only as static libraries, like
pgport, pgcommon, pgfeutils?
I assume there's some extensions that build binaries with pgxs, which then
presumably need pgport, pgcommon.
2) Would we want the option add it to autoconf and meson, or just meson?
3) For meson, I'd be inclined to leave the static libraries in as build
targets, but just not build and install them by default.
4) Why are we installing the static libraries into libdir? Given that they're
not versioned at all, it somehow seems pkglibdir would be more appropriate?
Debian apparently patches postgres in an attempt to do so:
https://salsa.debian.org/postgresql/postgresql/-/blob/15/debian/patches/libpgport-pkglibdir
but I think it's not quite complete, because the libpq.pc doesn't know
about the new location for the static libraries
5) currently we build the constituents of libpq.a with -fPIC, but then propose
to link with -lpgport -lpgcommon, rather than linking with the_shlib
versions. That seems a bit bogus to me - either we care about providing an
efficient non-PIC library (in which case libpq.a elements would need to be
build separately), or we don't (in which case we should just link to
*_shlib).
Greetings,
Andres Freund
