Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'

From: Mikael Sand <msand(at)seaber(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'
Date: 2024-10-10 22:25:06
Message-ID: CAAwAxZf8kgnGNtGCM2j_x7dXTtfA24XHa5QOUSTWC_R3MBAC0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Well for getting the potential benefits of link-time optimization into more
places, and slightly improved developer ergonomics, and perhaps mostly to
eliminate potential confusion if one needs pg_common and pg_ports or the
shared library version when compiling statically.
Would you happen to know if it is possible?

regards, mikael sand

On Fri, Oct 11, 2024 at 12:12 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Mikael Sand <msand(at)seaber(dot)io> writes:
> > I wonder if it would be possible to link pgcommon_shlib and pgport_shlib
> > statically into pq and do LTO already at that point, such that consumers
> of
> > libpq could merely link against libpq.a and that would be enough?
>
> What would be the point? A typical build will still have a pile of
> outside dependencies that static-link consumers will have to track
> manually (openssl and so forth). So I don't see how this'd move
> the needle much.
>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-10-10 22:28:26 Re: sunsetting md5 password support
Previous Message Tom Lane 2024-10-10 22:12:04 Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'