Native AOT Binaries still depend on libz.so

[hwoodiwiss]

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

1. Create a project with <PublishAot>true</PublishAot> and <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
2. Publish the container image with dotnet publish ./src/HwoodiwissHelper/HwoodiwissHelper.csproj --os linux --arch arm64 /t:PublishContainer
3. 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

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[jkotas]

@carlossanlop The problem is that libs.a is not included in the non-Windows native AOT packages. Could you please take a look?

It repros with simple Linux x64 publish. Arm64 and EnableSdkContainerSupport is not necessary for repro.

[jkotas]

Regression introduced by #104750

[hwoodiwiss]

This is unfortunately still an issue in RC1 (9.0.100-rc.1.24452.12), should this be reopened?

[carlossanlop]

@hwoodiwiss did you repro it again with the same instructions as in this issue's description?

[hwoodiwiss]

Yeah, it's the same build workflows, just having updated the sdk and libraries for RC1

[martincostello]

I'm failing to get some logs for some reason I need to investigate tomorrow, but I'm also getting startup failures in AWS Lambda for an AoT app using Amazon Linux 2023 with RC1 which might also be this issue.

[hwoodiwiss]

I've generated binlogs for linux arm64 and amd64, as I wanted to look, happy to share if they would be helpful.

From what I can see UseSystemZlib is evaluted to true, even though looking in package explorer at runtime.linux-arm64.Microsoft.DotNet.ILCompiler, it looks like libz.a should be present, which should cause Microsoft.NETCore.Native.Unix.targets#L27 not to set UseSystemZlib to true.

[hwoodiwiss]

Okay, just tested and confirmed a workaround for my usecase, manually setting <UseSystemZlib>false</UseSystemZlib> in my .csproj

[hwoodiwiss]

I've raised #107666 based on a what I think it could be from the binlogs

[martincostello]

I'm failing to get some logs for some reason I need to investigate tomorrow, but I'm also getting startup failures in AWS Lambda for an AoT app using Amazon Linux 2023 with RC1 which might also be this issue.

I'm still getting startup failures with the stated workaround, so I think I'm having a different problem. Will raise a new issue if it turns out not to be an issue with my app.

[martincostello]

I'm still getting startup failures with the stated workaround, so I think I'm having a different problem. Will raise a new issue if it turns out not to be an issue with my app.

I've established that whatever the issue I'm having is, it's not anything todo with zlib.