aws-lambda-go: /lib64/libc.so.6: version `GLIBC_2.32' not found when building on linux

I was running into this error when I followed the instructions in the README:

/var/task/main: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /var/task/main)

I managed to fix it via by setting CGO_ENABLED=0 when building on linux, similar to the instructions for windows, ie

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

Should that be included in the README, or is there a better way to fix this?

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 65
  • Comments: 28

Commits related to this issue

Most upvoted comments

I ran into this while using the SAM CLI.

The fix was ultimately the suggestion to use CGO_ENABLED=0 but I had to take some additional steps to make this work with sam, see https://github.com/aws/aws-sam-cli/issues/3894 for the breadcrumbs.

Documented the approach for my project here: https://www.gaunt.dev/blog/2022/glibc-error-with-aws-sam-and-go/

Affected by the same issue. Trying to use SQLite with go on lambda is painful.

Hello? 3 years passed and still not resolved?

@smark-d here’s my build command from my makefile. i build on manjaro and deploy through the serverless framework to lambda and it works fine. go is v1.20.

build: clean
	env GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/api cmd/api/api.go
	zip bin/api.zip bin/api
	env GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/async cmd/async/async.go
	zip bin/async.zip bin/async
	env GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/schedule cmd/schedule/schedule.go
	zip bin/schedule.zip bin/schedule

clean:
	rm -rfv ./bin

Now it’s working, thanks a lot. I think it’s due to cache issues, after remove the funcation and rebuild , it’s woking now.

This was absolutely terrifying to discover last minute. I recently switched all 4 of my PCs from Ubuntu to Manjaro and right as I was deploying some new code this issue popped up. I’m extremely lucky all I had to do was add CGO_ENABLED=0 to the build flags to fix it but this is a last minute dependency I didn’t even know existed in my build pipeline.

I have no idea why Manjaro needs a new build flag versus Ubuntu unfortunately - that’s definitely not an area of expertise for me.

@gauntface that will only work if your project does not depend on cgo. In my (and others here) case, I required cgo for go-sqlite3, which requires special compilation specifically for the Lambda Go runtime environment.

Hello? 3 years passed and still not resolved?

Amazon doesn’t care about open source

And people don’t appear to read the FIRST POST at the top that literally tells you how to solve it. This is a common Linux building issue.

Hello? 3 years passed and still not resolved?

Amazon doesn’t care about open source

Finally got it working but my process of trial and error doesnt seem that elegant. It works with this image: public.ecr.aws/lambda/go:1.2022.11.03.18 which installed glibc-devel-2.17-324.189.amzn1.x86_64 as part of the golang install.

Open to suggestions\advice on why this is happening or anything i can do to improve it. Thanks.

Just ran into this myself also trying to use go-sqlite3. @HSchmale16 did you ever find a way to get it to work?

I ended up building and deploying from cloudshell. Had to move the GOPATH to outside of the home directory. I still haven’t fully understood what lambda is doing with it.