Skip to main content
Ask Linky AI ⌘K

Glibc 2.43 Release – Impact on apk add and Chainguard Images

Summary (TL;DR)

If you see runtime errors like:

cannot load GLIBC_2.43

you are most likely:

  • Running older Chainguard/Wolfi images that contain glibc 2.42 (or earlier), and
  • Installing or upgrading packages with apk add from repositories that now ship glibc 2.43.

Resolution: Update to the latest image for your workload and rebuild/redeploy. Avoid mixing old base images with newer packages that require glibc 2.43.

Applies to

This article applies when all of the following are true:

  • You are running Chainguard/Wolfi-based container images, and
  • Those images include glibc 2.42 or older, and
  • You are using apk add (or apk upgrade) to install or update packages from Chainguard/Wolfi repositories that now depend on glibc 2.43.

What changed?

  • glibc 2.43 has been released and is now available in Chainguard/Wolfi package repositories.
  • New or updated packages in these repositories may now be built against glibc 2.43.
  • If you continue using older images (e.g., with glibc 2.42) and then install latest packages via apk add, you may end up with binaries that require glibc 2.43 running on a system that only ships glibc 2.42.

This crosses the ABI boundary and can cause runtime loader failures.

Symptoms

You are likely impacted if:

  • Your workloads run on older images (for example, still on glibc 2.42), and
  • You install or upgrade packages with apk add from a repository that has moved to glibc 2.43.

Typical errors look like:

cannot load GLIBC_2.43

These errors generally occur at application startup, when a binary that requires glibc 2.43 runs in a container where only glibc 2.42 is available.

Root cause

  • New packages are built against glibc 2.43.
  • Older base images still ship glibc 2.42.
  • Installing/using those newer packages on the older image causes an ABI mismatch:
    • The binary expects symbols from glibc 2.43.
    • The runtime only provides glibc 2.42.
  • The dynamic loader fails to resolve the required symbol versions and reports errors like cannot load GLIBC_2.43.

Recommended actions

1. Use the latest images

If you see cannot load GLIBC_2.43:

  1. Pull the latest version of the relevant Chainguard image.
  2. Rebuild and redeploy your workloads using that updated image.

Examples:

# Pull latest version explicitly
docker pull <your-chainguard-image>

# Always pull latest before run
docker run --pull=always <your-chainguard-image> ...

# Rebuild images without using cache
docker build --no-cache -t <your-image-tag> <build-context>

Replace <your-chainguard-image>, <your-image-tag>, and <build-context> with values appropriate for your environment.

2. Be aware of local image repositories

If you use a private registry or on‑premises cache:

  • It may not yet have synchronized the newest Chainguard images that contain glibc 2.43.
  • Ensure that your registry has pulled or mirrored the latest images before rebuilding.

Actions:

  • Check that the registry has the latest tags for your Chainguard images.
  • Force a refresh or re-sync if necessary.
  • After confirming, rebuild and redeploy your workloads against images that include glibc 2.43 (or newer).

3. Avoid mixing old base images with new packages

To prevent ABI issues:

  • Do not:
    • Keep an older base image (e.g., with glibc 2.42) and continually apk add or apk upgrade from a repository that has moved to glibc 2.43.
  • Do:
    • Regularly refresh your base image to a current tag that includes glibc 2.43.
    • Align image and package sources so they are built against the same glibc version.

How to check which glibc version your image uses

You can confirm the glibc version in your image using either:

  • Option 1: Inspect the SBOM inside the container.
  • Option 2: Run the libc.so.6 binary directly (especially useful for minimal/distroless images).

Option 1: Check glibc via the SBOM

  1. Start a shell in your image (example with wolfi-base):

    docker run -it chainguard/wolfi-base

  2. Inside the container, list the glibc SBOM entries:

    ls -l /var/lib/db/sbom/glibc-*

  3. Example output:

    -rw-r--r-- 1 root root 5396 Jan 26 15:27 /var/lib/db/sbom/glibc-2.42-r7.spdx.json
-rw-r--r-- 1 root root 7253 Jan 26 15:27 /var/lib/db/sbom/glibc-locale-posix-2.42-r7.spdx.json

    In this example, the image is using glibc 2.42, which is older than 2.43. If you install packages built against glibc 2.43 into this container, you may hit cannot load GLIBC_2.43 at runtime.

Option 2: Run libc.so.6 directly (distroless-friendly)

For more minimal or distroless images, you can query the glibc version by running the libc.so.6 binary directly:

docker run --entrypoint /usr/lib/libc.so.6 chainguard/nginx

Example output:

GNU C Library (glibc-2.42-r8) stable release version 2.42.
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 15.2.0.
libc ABIs: UNIQUE ABSOLUTE
Minimum supported kernel: 4.9.0
For bug reporting instructions, please see:
&lt;https://www.gnu.org/software/libc/bugs.html&gt;.

This output clearly shows glibc 2.42.

Interpreting the examples

In both the SBOM and libc.so.6 examples:

  • The image is running glibc 2.42.

  • If you install or run software that expects glibc 2.43, you risk ABI-related runtime failures such as:

    cannot load GLIBC_2.43

To avoid these issues:

  • Prefer fresh images that already include glibc 2.43 (or newer).
  • Avoid mixing old base images with newly built or updated packages that depend on the newer glibc.

Quick checklist

Use this checklist if you encounter glibc-related errors:

  • Check if error messages mention cannot load GLIBC_2.43 (or similar).
  • Confirm you are using the latest Chainguard image for your workload.
  • If using a local or private registry, verify it has synced the newest images.
  • Inspect the image’s glibc version via one of:
    • SBOM: ls -l /var/lib/db/sbom/glibc-* inside the container.
    • libc.so.6: run /usr/lib/libc.so.6 as the container entrypoint.
  • If the image is still on glibc 2.42, update to an image that includes glibc 2.43 before installing or running packages built against 2.43.
  • Rebuild and redeploy workloads using the updated images.

By keeping your base images and installed packages aligned on the same glibc version, you can avoid ABI mismatches and runtime loader errors.

Related to

Related articles

Comments

0 comments

Please sign in to leave a comment.