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: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'
Date: 2024-10-10 19:08:53
Message-ID: CAAwAxZdnMQWsYj59-uh8SGAEkZRDDr+xtuvr8hELhP2A9nfN6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aleksander, do you have something against static linking or am I reading
you wrong?
I've seen this sentiment in several places but never understood why anyone
would hold this position. Could you elaborate?

At least for executables intended to be run in production inside
containers, they usually run in isolation, what other executables could
they share libraries with?
Should we leave performance on the table, given the energy and resource
requirements it implies?

Certainly, for libraries intended to be distributed in e.g. Linux
distributions and be depended on in end-user executables, it makes sense to
have shared libraries and simplify mitigating security issues.

It appears to me that there are many cases where static linking and link
time optimization would be more appropriate than dynamic.
When the executables never have a chance to share libraries with any other
process and are rebuilt whenever a new version is deployed what benefits
does dynamic linking provide over static + lto?

I expect I'm missing something crucial, but I have spent some time trying
to understand this issue deeper, and still find myself mystified.
Please enlighten me.

Br Mikael

On Thu, Oct 10, 2024 at 8:29 PM Mikael Sand <msand(at)seaber(dot)io> wrote:

> Just for reference in case anyone else who utilizes static linking for any
> reason hits upon this issue, here is a working Dockerfile for libpq /
> postgresql 17
>
> FROM postgres:17.0-alpine3.20 AS builder
> USER root
> WORKDIR /app
> RUN apk update && apk add --no-cache --update-cache \
> openssl-libs-static \
> libevent-static \
> libxml2-static \
> libedit-static \
> libxslt-static \
> sqlite-static \
> openldap-dev \
> libxslt-dev \
> libxml2-dev \
> libedit-dev \
> openssl-dev \
> zstd-static \
> zlib-static \
> lz4-static \
> e2fsprogs \
> keyutils \
> zstd-dev \
> zlib-dev \
> gdbm-dev \
> clang17 \
> lz4-dev \
> libldap \
> bison \
> curl \
> perl \
> make
>
> COPY <<EOF ./main.cpp
> #include<libpq-fe.h>
> int main(){return PQconnectdb("")==NULL;}
> EOF
>
> ARG KRB5=1.21.3
> ARG KRB5MAJMIN=1.21
> RUN curl -L https://kerberos.org/dist/krb5/$KRB5MAJMIN/krb5-$KRB5.tar.gz | tar xzf -
> RUN cd krb5-$KRB5/src && \
> ./configure && make && make install && \
> ./configure --disable-shared --enable-static && make && make install
>
> ARG SASL=2.1.28
> RUN curl -L https://github.com/cyrusimap/cyrus-sasl/releases/download/cyrus-sasl-$SASL/cyrus-sasl-$SASL.tar.gz | tar xzf -
> RUN cd cyrus-sasl-$SASL && ./configure --enable-static && make && make install
>
> RUN clang++ -static -o main main.cpp \
> -L/usr/local/lib -lpq -lpgcommon_shlib -lpgport_shlib \
> -lldap -lsasl2 -lssl -lcrypto -llber \
> -lgssapi_krb5 \
> -lkrb5 -lk5crypto -lcom_err -lkrb5support \
> -lgdbm
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2024-10-10 19:49:16 Re: Statistics Import and Export
Previous Message Tom Lane 2024-10-10 19:07:48 Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'