Tom
Would this be an acceptable patch?
Subject: [PATCH] Fix static build
---
Index: src/Makefile.shlib
<+>UTF-8
===================================================================
diff --git a/src/Makefile.shlib b/src/Makefile.shlib
--- a/src/Makefile.shlib (revision fd64ed60b62697984bb69a09a3ae19fbe2905eb6)
+++ b/src/Makefile.shlib (date 1728590127913)
@@ -354,7 +354,7 @@
# those that point inside the build or source tree. Use sort to
# remove duplicates. Also record the -l flags necessary for static
# linking, but not those already covered by Requires.private.
- echo 'Libs.private: $(sort $(filter-out -L.% -L$(top_srcdir)/%,$(filter
-L%,$(LDFLAGS) $(SHLIB_LINK)))) $(filter-out
$(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter
-l%,$(SHLIB_LINK_INTERNAL:%_shlib=%) $(SHLIB_LINK)))' >>$@
+ echo 'Libs.private: $(sort $(filter-out -L.% -L$(top_srcdir)/%,$(filter
-L%,$(LDFLAGS) $(SHLIB_LINK)))) $(filter-out
$(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter -l%,$(SHLIB_LINK_INTERNAL)
$(SHLIB_LINK)))' >>$@
##
Br Mikael
On Thu, Oct 10, 2024 at 9:08 PM Mikael Sand <ms...@seaber.io> wrote:
> 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 <ms...@seaber.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
>>
>>
