Description
Description
Based on dotnet/dotnet-docker#5792, libz.so has been removed from the runtime-deps image for .NET 9, however, when trying to run an application AOT compiled for ARM64 and containerized, an error is thrown:
/app/HwoodiwissHelper: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file
Which indicates that the build is still dependant on zlib as a shared library, rather than statically linked/included in the output executable as indicated by the discussion linked in the announcement.
Reproduction Steps
- Create a project with
<PublishAot>true</PublishAot>and<EnableSdkContainerSupport>true</EnableSdkContainerSupport> - Publish the container image with
dotnet publish ./src/HwoodiwissHelper/HwoodiwissHelper.csproj --os linux --arch arm64 /t:PublishContainer - Pull and attempt to run the container
Edit -
Mentioned in @jkotas comment, the containerization doesn't make a difference, I would guess it just provides a sterile enough environment for this issue to show itself.
Expected behavior
The container should start and run the native compiled binary
Actual behavior
App startup fails, with error message /app/HwoodiwissHelper: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file
Regression?
No response
Known Workarounds
Manually add <UseSystemZlib>false</UseSystemZlib> to your projects properties, to force libz.a to be statically linked.
Configuration
ARM64
.NET Version: .NET 9.0.0-preview.7.24405.7, 9.0.100-rc.1.24452.12
Container base image: mcr.microsoft.com/dotnet/nightly/runtime-deps:9.0.0-preview.7-noble-chiseled-aot (automatically pulled by SDK container publish on 2024-08-16), running on containerd on Debian GNU/Linux 12 (bookworm) (Raspberry Pi)
AMD64
.NET Version: .NET 9.0.0-preview.7.24405.7, 9.0.100-rc.1.24452.12
Tested on Docker (WSL) on Windows
Other information
No response