Fails to build on Debian Trixie with static linking #3976

Activity

1. jmccl

   added

   bugThis issue is a bug.This issue is a bug.

   needs-triageThis issue or PR still needs to be triaged.This issue or PR still needs to be triaged.

   on Nov 2, 2026
2. sbiscigl commented on Nov 2, 2026

   

   sbiscigl

   on Nov 2, 2026

   Contributor

   More actions

   Hey thanks for reaching out, was unaware Debian started building their OpenSSL with zstd. Since static libraries don't carry their dependencies, if you're linking statically, now everything with an OpenSSL dependency needs to link zstd, not just the SDK. That's on how Debian packages OpenSSL rather than the SDK, but you have three options to work around it.

   1. add it as a parameter when building (fast and easy)

   install libzstd-dev and add the cmake configuration option -DCMAKE_CXX_STANDARD_LIBRARIES="-lzstd", which will link zstd when the SDK's tests are built. you'll also need to add zstd when linking your own application against the static SDK.

   this will continue to use the system openssl

   sample docker image working:

   FROM public.ecr.aws/debian/debian:trixie
   
   RUN apt-get update && apt-get install -y --no-install-recommends \
           build-essential \
           ca-certificates \
           cmake \
           git \
           libcurl4-openssl-dev \
           libssl-dev \
           libzstd-dev \
           zlib1g-dev \
       && rm -rf /var/lib/apt/lists/*
   
   ARG SDK_REF=main
   RUN git clone --depth 1 --branch ${SDK_REF} --recurse-submodules --shallow-submodules \
           https://github.com/aws/aws-sdk-cpp.git /aws-sdk-cpp
   
   WORKDIR /aws-sdk-cpp/build
   
   RUN cmake .. \
           -DCMAKE_BUILD_TYPE=Release \
           -DSTATIC_LINKING=1 \
           -DBUILD_ONLY="core" \
           -DCMAKE_CXX_STANDARD_LIBRARIES="-lzstd"
   
   ARG JOBS=8
   RUN make -j${JOBS}

   2. Just use aws-lc

   configure with -DUSE_OPENSSL=OFF, which will use the aws-lc project that already exists in the build tree, skipping system openssl entirely. this has runtime consequences as updating system libcrypto won't update the version the SDK is running with, however this will use the packaged version of crypto in our dependency set.

   sample docker image working:

   FROM public.ecr.aws/debian/debian:trixie
   
   RUN apt-get update && apt-get install -y --no-install-recommends \
           build-essential \
           ca-certificates \
           cmake \
           git \
           libcurl4-openssl-dev \
           libssl-dev \
           zlib1g-dev \
       && rm -rf /var/lib/apt/lists/*
   
   ARG SDK_REF=main
   RUN git clone --depth 1 --branch ${SDK_REF} --recurse-submodules --shallow-submodules \
           https://github.com/aws/aws-sdk-cpp.git /aws-sdk-cpp
   
   WORKDIR /aws-sdk-cpp/build
   
   RUN cmake .. \
           -DCMAKE_BUILD_TYPE=Release \
           -DSTATIC_LINKING=1 \
           -DBUILD_ONLY="core" \
           -DUSE_OPENSSL=OFF
   
   ARG JOBS=8
   RUN make -j${JOBS}

   3. contact s2n, and aws-c-cal to update their Findcrypto cmake files.
      aws-c-cal
      s2n

   the SDK doesn't actually pick your crypto, the dependencies you build alongside the SDK do. they have a cmake module that finds and links libcrypto. updating those to pull in zstd would be the cmake recipe location to bring it in.
3. sbiscigl

   added

   response-requestedWaiting on additional info and feedback. Will move to "closing-soon" in 10 days.Waiting on additional info and feedback. Will move to "closing-soon" in 10 days.

   build-problemproblems with building this sdkproblems with building this sdk

   and removed

   bugThis issue is a bug.This issue is a bug.

   needs-triageThis issue or PR still needs to be triaged.This issue or PR still needs to be triaged.

   on Nov 2, 2026
4. jmccl commented on Nov 4, 2026

   

   jmccl

   on Nov 4, 2026

   Last edited by jmccl

   Author

   More actions

   Thanks for the suggestions. #1 helps a lot.

   However, my impression is this a a openssl 3.5+ and static linking issue, not a Debian issue as such.

   (The CMake magic needs to be '-DCMAKE_CXX_STANDARD_LIBRARIES="-lzstd -lz"', fwiw)
5. sbiscigl commented on Nov 4, 2026

   

   sbiscigl

   on Nov 4, 2026

   Last edited by sbiscigl

   Contributor

   More actions

   However, my impression is this a a openssl 3.5+ and static linking issue, not a Debian issue as such.

   yeah youre right, in that case option 3 is what you would need to go with, and aws-c-cal and s2n would need to update their find crypto scripts to respect linking zstd. however option 2 would be preferred to that, as its using the packaged libcrypto in the build tree.

   also from the s2n documenation they specifically call out

   Today s2n-tls supports AWS-LC, OpenSSL (versions 1.0.2, 1.1.1, 3.0.x, and temporarily 4.0), LibreSSL, and BoringSSL to perform the underlying cryptographic operations.

   so they only plan on supporting those versions, if you want them to support higher versions thats a feature request they would need to work on. being that is their support matrix i would even callout out using 3.1.x+ as a potential support risk.

   (The CMake magic needs to be '-DCMAKE_CXX_STANDARD_LIBRARIES="-lzstd -lz"', fwiw)

   the dockerfile above builds as written, curious why you need "lz"? or ar you referring to your build process and not the dockerfile from above?