From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pyry Kontio <pyry(dot)kontio(at)drasa(dot)eu> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Adding libpgcommon and libpgcore to libpq pkg-config's Requires.private |
Date: | 2020-02-17 14:04:52 |
Message-ID: | 32416.1581948292@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Pyry Kontio <pyry(dot)kontio(at)drasa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hazuki Amamiya | 2020-02-17 16:04:40 | Possible memory leak in PostgreSQL 12.2 on truncate, insert or delete when type interval is involved |
Previous Message | Daniel Gustafsson | 2020-02-17 13:57:10 | Re: BUG #16261: Not able to start Postgres |