Обсуждение: Adding libpgcommon and libpgcore to libpq pkg-config's Requires.private

Hi,

I recently investigated a build with statically linked libpq
that broke on update to PostgreSQL 12.0.

The problem was that starting from 12.0, libpq doesn't
include some required files via symlinks anymore,
and needs to be linked against libpgcommon and
libpgcore. (When dynamically linking, this problem
doesn't manifest.)

(Ref: my earlier mail.
https://www.postgresql.org/message-id/CACS8yHL0gbL3ECONrDygcBioTQBY%3DoVG-KGWB6%2BN7spG%2BeSMQw%40mail.gmail.com)

However, the pkg-config file for libpq doesn't reflect that fact.
I think that this should be considered as a bug; I think that
libpq's pkg-config file should be have libpgcommon and libpgcore
on the Libs.private row like this:

Libs.private: -L/musl/lib/ -lm -lpgcommon -lpgport

That would allow scripts that get their linking flags from
pkg-config to correctly build libpq even when doing a static build.

Let me hear what you think.

All the best,
Pyry Kontio

Pyry Kontio <pyry.kontio@drasa.eu> writes:
> I recently investigated a build with statically linked libpq
> that broke on update to PostgreSQL 12.0.

> The problem was that starting from 12.0, libpq doesn't
> include some required files via symlinks anymore,
> and needs to be linked against libpgcommon and
> libpgcore. (When dynamically linking, this problem
> doesn't manifest.)

Correct.

> However, the pkg-config file for libpq doesn't reflect that fact.
> I think that this should be considered as a bug;

We do not support statically-linked libpq, so this is not a bug.

If you are going to distribute a statically-linked libpq, you can
distribute a modified pkg-config file alongside it, but please
make clear to your users that such a configuration is not standard
Postgres and is not supported or approved by upstream.

The primary reason why I'm pushing back so hard against this is
that in the configuration you suggest, there's no way to avoid
exposing all the cruft in libpgcommon and libpgport to client
applications.  That's a horrible situation and will inevitably
lead to ABI problems.  Which we will *NOT* acknowledge as being
our bug to deal with, and we are not going to be happy that
you made it possible.

            regards, tom lane