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
>
>
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' |