lxml build failing on older Wolfi image with -lgcc_s_asneeded linker error

[vmalhotra7]

Today I encountered an issue while building the lxml wheel from source on a Wolfi-based image. The build fails during the linking stage with the following error:

running build_ext
building 'lxml.etree' extension
creating build/temp.linux-x86_64-cpython-311/src/lxml
x86_64-pc-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -I/usr/include/libxml2 -Isrc -Isrc/lxml/includes -I/usr/include/python3.11 -c src/lxml/etree.c -o build/temp.linux-x86_64-cpython-311/src/lxml/etree.o -w
x86_64-pc-linux-gnu-gcc -shared build/temp.linux-x86_64-cpython-311/src/lxml/etree.o -L/usr/lib -lxslt -lexslt -lxml2 -lrt -lz -lm -o build/lib.linux-x86_64-cpython-311/lxml/etree.cpython-311-x86_64-linux-gnu.so
/usr/x86_64-pc-linux-gnu/bin/ld: cannot find -lgcc_s_asneeded: No such file or directory
collect2: error: ld returned 1 exit status
error: command '/usr/local/bin/x86_64-pc-linux-gnu-gcc' failed with exit code 1

ERROR: Failed building wheel for lxml
Failed to build lxml
error: failed-wheel-build-for-install
× Failed to build installable wheels for some pyproject.toml based projects
╰─> lxml

Observation:

This issue occurs on a Wolfi image that is ~3 days old.
The same build works successfully when using the latest Wolfi image.

Question:

Was there any recent change in the Wolfi toolchain (e.g., gcc/libgcc/binutils packaging) that could explain this behavior?

Specifically, the linker is unable to resolve -lgcc_s_asneeded, which suggests a possible change in how libgcc or related runtime components are packaged or included.

Alternatively, is this expected behavior due to the rolling nature of Wolfi repositories, where older images may become incompatible with newer package indexes?

Any pointers or clarification would be helpful.

[xnox]

The asneeded changes are related to recent GCC 16 work. If your environment uses rolling "build-base" or "gcc" packages the older base image indeed can become stale and incompatible with a brand new toolchain. Most likely if you install "gcc-15-default" the build will likely work with both old and fresh container images as a starting point. In general, we always recommend to do all builds with fresh base images (for example docker run --pull=always or docker build --no-cache.)

The gss_s_asneeded changes are related to supporting GCC 16 and bootstrapping various toolchains.

Also pinging @sergiodj who might have more technical details about this.

[sergiodj]

Yes, what @xnox said. Plus the fact that this specific problem was addressed yesterday, so if you're using GCC 16 16.1.0-r1 you should be good.

[vmalhotra7]

I was installing gcc, which I guess was auto-referring to 16.1.0-r1, but still faced the same issue. Is there any notification or place we can check if these are updated or if fixes are made? a pr ref will also do.

[sergiodj]

Can you double check the GCC version you were using, please? The problem should be addressed in the -r1 version, unless you're statically linking using cmake (I'm working on a fix for this specific scenario).