/lib64/libc.so.6: version `GLIBC_2.32' not found

Question

I'm building the lambda on Ubuntu with the basic example. It builds without any errors but if I upload and test it on aws in crashes with:

{
  "errorMessage": "RequestId: 7f4d0aca-125c-4032-98dd-9ff387e5252b Error: Runtime exited with error: exit status 1",
  "errorType": "Runtime.ExitError"
}

The log output is:

START
RequestId: 7f4d0aca-125c-4032-98dd-9ff387e5252b
Version: $LATEST.~.jwtauthorizeraws.jwtauthorizerawsapplication: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./~.jwtauthorizerawsapplication)
END 
RequestId: 7f4d0aca-125c-4032-98dd-9ff387e5252b
REPORT
RequestId: 7f4d0aca-125c-4032-98dd-9ff387e5252b
Duration: 56.02 ms
Billed Duration: 57 ms
Memory Size: 128 MB
Max Memory Used: 7 MB   
RequestId: 7f4d0aca-125c-4032-98dd-9ff387e5252b
Error: Runtime exited with error: exit status 1
Runtime.ExitError

Answer 1

the environment you are executing the seems doesn't provide a Glibc version in version 2.32.

This can have several problems: the version of your the Lambda env is older, or it doesn't provide an GlibC at all (which can be the case).

if you application would be pure java (without creating an native app via graal) it would run since the java app itself doesn't depend a version of GLibC, the requirment comes from the native app.

Answer 2

It probably means that the glibc version used to build the executable is different than the docker environment is using.

So, check the build environment ldd --version will reveal the glibc version.

Now, in your docker container (docker run -ti --entrypoint=/bin/bash dockerimage:tag) type the same ldd command. You'll probably see that the versions are different. So, update either the build environment to use the same version as the docker environment or vice-versa.

The best way to avoid this is to use the runtime environment to build your native executable: this way the glibc version will always match.

Answer 3

FWIW, in Quarkus, we have a feature called in-container build, which allows to create your native image inside a container that is compatible with the runtime images we use.

Using -Dquarkus.native.container-build=true makes it happen.

Not saying you should migrate to Quarkus but if you want to build native images, you really need to build them in an environment compatible with your runtime environment so you will end up having to build in a container.

Answer 4

I recently ran into this issue.

Build your project with CGO_ENABLED=0 may be enough to fix your issue:

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o main main.go

If you are using sam, there is a --use-container flag, however this may not work for golang projects

To make sam build use a custom build command, i.e. run the go build command above, you can set the BuildMethod to makefile and create a Makefile with a target with the name build-<YourFunctionName>.

HealthCheckFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: makefile
    Properties:
      CodeUri: .
      Handler: healthcheck
      FunctionName: !Sub "healthcheck_${Env}"
      Runtime: go1.x
      Architectures:
        - x86_64
      Events:
        ...

Then the Makefile would have:

build-HealthCheckFunction:
  GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o healthcheck lambda/healthcheck/healthcheck.go
  mv healthcheck $(ARTIFACTS_DIR)

More details here on what I had to do to get this fixed in my project: https://www.gaunt.dev/blog/2022/glibc-error-with-aws-sam-and-go/