.NET ARM Lambda function using .NET 7 RC1 fails to start when using a custom runtime

[martincostello]

Describe the bug

With .NET RC1 available today, I attempted to deploy a .NET Lambda function I have to use it via a custom runtime (deployment).

However, once deployed the tests for the Lambda function showed it was failing with an error. Digging into the logs in CloudWatch show that the function is failing to start.

Failed to load /var/task/libcoreclr.so, error: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /var/task/libcoreclr.so)

This appears to be due to the AWS Lambda runtime not having the correct version of GLIBC (2.27) for .NET 7 to run, likely due to a change in the native requirements for .NET itself.

I'm not currently aware of a way to get a .NET application to publish a specific version of GLIBC with the compiled application - if there is one, I'm all ears to unblock early adoption.

Expected Behavior

The Lambda function initializes successfully.

Current Behavior

The Lambda function fails to initialise with the following error:

Failed to load /var/task/libcoreclr.so, error: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /var/task/libcoreclr.so)
RequestId: {GUID} Error: Runtime exited with error: signal: segmentation fault
Runtime.ExitError

Reproduction Steps

An AWS Lambda function derived from martincostello/alexa-london-travel at commit bfc8db1850aa3b6463ffd23fc96b76a730222e61 when deployed to AWS Lambda using the provided.al2 runtime will fail to initialize.

Possible Solution

1. If there's a way to manually include the appropriate version with GLIBC as part of the dotnet publish output from the AWS Lambda global tool.
2. The AWS Linux 2 runtime has a newer version of GLIBC installed on it that is at least version 2.27.

Additional Information/Context

No response

AWS .NET SDK and/or Package version used

Amazon.Lambda.RuntimeSupport 1.8.2

Targeted .NET Platform

.NET 7 Release Candidate 1

Operating System and version

Linux 4.14.255-276-224.499.amzn2.aarch64 #1 SMP Tue May 3 22:29:59 UTC 2022

[martincostello]

Also logged with Microsoft here: dotnet/runtime#75622

[normj]

Hi @martincostello were you getting the error for ARM or X64? I have reproduced the problem for ARM but not for X64. I'm not sure what are options are yet because getting provided.al2 updated to have a newer version of GLIBC could be a tough sell to the Lambda team but I'll see what I can do.

[martincostello]

Sorry for not making that clear, this is with Graviton and arm64.

[martincostello]

I've switched the function to x64 and re-deployed it with .NET 7 and now it's working as expected.

For my use case here that's an acceptable workaround until we can come up with a solution for arm64.

[normj]

Thanks for confirming. I'll see what I can do on my side about it. I suspect we are stuck on the ARM side till we have a managed .NET 8 runtime or Lambda offers an AL2022 provided runtime.

[Simonl9l]

@norm any next steps here this is really killing us.

We have developers on M1 Apple Silicon, that are unable to cross compile (via Docker) to linux/x86_64 and the docker/qemu environment does not currently support it at all due to multiple layers of emulation.