Different GLIBC version in Torizon between debian-cross-toolchain and debian

I am trying to compile a C++ application using a Dockerfile for TorizonCore. Using the template C++ project as a basis and changing it for my app (which uses vcpkg and cmake) I arrived there:

ARG CROSS_SDK_BASE_TAG=3-bookworm
ARG BASE_VERSION=3-bookworm
ARG IMAGE_ARCH=arm64

ARG APP_EXECUTABLE=my_application

# BUILD ------------------------------------------------------------------------
FROM torizon/debian-cross-toolchain-${IMAGE_ARCH}:${CROSS_SDK_BASE_TAG} As Build

ARG IMAGE_ARCH
ARG COMPILER_ARCH
ENV IMAGE_ARCH ${IMAGE_ARCH}

# __deps__
RUN apt-get -q -y update && \
    apt-get -q -y install \
    clang-tidy \
    cmake \
    cppcheck \
    curl \
    iwyu \
    mono-complete \
    ninja-build \
    pkg-config \
    python3 \
    unzip \
    uuid-dev uuid-runtime \
    zip \
# DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
    # __torizon_packages_dev_start__
    # __torizon_packages_dev_end__
# DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
    && \
    apt-get clean && apt-get autoremove && \
    rm -rf /var/lib/apt/lists/*
# __deps__

# Download vcpkg
RUN git clone --branch 2023.01.09 https://github.com/microsoft/vcpkg

# Setup vcpkg
RUN cd vcpkg && \
    ./bootstrap-vcpkg.sh && \
    cd / && \
    chmod -R 777 vcpkg

# Set environment variables
ENV VCPKG_ROOT="/vcpkg"

COPY . /app
WORKDIR /app

RUN if [ "$IMAGE_ARCH" = "arm64" ] ; then \
        cmake --preset ci-aarch64 . && \
        cmake --build build/ --target my_application_exe ; \
        mkdir -p aarch64/bin aarch64/debug aarch64/obj ; \
        cp build/my_application aarch64/bin ; \
    fi
# BUILD ------------------------------------------------------------------------

# DEPLOY ------------------------------------------------------------------------
FROM --platform=linux/${IMAGE_ARCH} torizon/debian:${BASE_VERSION} AS Deploy

ARG IMAGE_ARCH
ARG APP_EXECUTABLE
ENV APP_EXECUTABLE ${APP_EXECUTABLE}

RUN apt-get -y update && apt-get install -y --no-install-recommends \
# DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
    # __torizon_packages_prod_start__
    # __torizon_packages_prod_end__
# DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
	&& apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/*

# copy the build
COPY --from=Build /app/aarch64/bin /app

# ADD YOUR ARGUMENTS HERE
#CMD [ "./app/my_application" ]

# DEPLOY ------------------------------------------------------------------------

But, there is a difference in glibc version between the debian-cross-toolchain and the debian images.
For the debian-cross-toolchain image:

root@ec84cfa702a5:/# ./usr/aarch64-linux-gnu/lib/libc.so.6 
GNU C Library (Debian GLIBC 2.36-3) stable release version 2.36.

For the debian image:

root@6c0c42755a7b:/# /lib/aarch64-linux-gnu/libc.so.6 
GNU C Library (Debian GLIBC 2.34-3) stable release version 2.34.

Thus, launching my application, I get /lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.36' not found (required by ./my_application)

Greetings @mnano,

I was able to reproduce this on my side as well. I think I know what’s wrong it seems our Debian container is using a snapshot of the package-feed. I imagine this snapshot uses an older version of the glibc package which would explain this discrepancy. Let me check with our team on this and get back to you.

Best Regards,
Jeremias

After consulting internally, it was said our debian-bookworm containers are still a bit of a work-in-progress. So for the time being it’s recommended to use the debian-bullseye containers if you can. At least until our debian-bookworm containers are fully ready.

Best Regards,
Jeremias

Hello,

Thank you for the quick feedback.

Do you have an estimate for when the debian-bookwork containers would be ready?
Or, would you happen to know of a temporary workaround for this problem if I want to keep using debian-bookwork?

Edit: I could make everything work with debian-bullseye by manually installing the dependencies that needed a higher version than what the package offers (I needed cmake 3.19 for example and bullseye only goes to 3.18)

Glad you were able to find a workaround.

Do you have an estimate for when the debian-bookwork containers would be ready?

I don’t really have a hard time-line for when this work will be done other than “soon”. However, the plan is to have these containers available and ready for the next 6.2.0 quarterly release.

Or, would you happen to know of a temporary workaround for this problem if I want to keep using debian-bookwork?

You could re-build the containers with synchronized glibc packages. However, the source Dockerfiles are not open to the public yet and the containers themselves still have some fine-tuning and testing to be done.

Best Regards,
Jeremias