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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mikael Sand <msand(at)seaber(dot)io>
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:12:04
Message-ID: 2733190.1728598324@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikael Sand 2024-10-10 22:25:06 Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'
Previous Message Masahiko Sawada 2024-10-10 22:10:02 Re: Using per-transaction memory contexts for storing decoded tuples