aws-lambda-rust-runtime: /lib64/libc.so.6: version `GLIBC_2.18' not found

I had all the same issues. I was building on a mac. I went the docker build route after running into OpenSSL linking issues.

I had to use the lambci/lambda:build-provided image instead. The image mentioned here resulted in SSL errors when I ran the lambda function in AWS.

/var/task/bootstrap: /lib64/libcrypto.so.10: version `OPENSSL_1.0.2' not found (required by /var/task/bootstrap)

Here is my Dockerfile

FROM lambci/lambda:build-provided
RUN curl https://sh.rustup.rs -sSf | /bin/sh -s -- -y
ENV PATH="/root/.cargo/bin:${PATH}"
RUN rustup install stable
# RUN yum install -y gcc gcc-c++ make openssl openssl-devel
RUN mkdir /code
WORKDIR /code

Then I ran

docker build . -t lambda_builder

docker run --rm -v ${PWD}:/code -v ${HOME}/.cargo/registry:/root/.cargo/registry -v ${HOME}/.cargo/git:/root/.cargo/git lambda_builder cargo build --release
zip -j lambda.zip target/release/bootstrap

Since most of my day-to-day work is on a Mac, I’ve used Cross (which recently merged support for macOS!) to build the Lambda function.

$ cargo install --force --git https://github.com/rust-embedded/cross # this pulls from master, only needed once
$ cross build --release --target x86_64-unknown-linux-musl

Note: Cross has a Docker dependency. I’ve been using Docker Desktop for Mac pretty happily.

That doc is still true but when expanded, you’ve got options.

For local builds musl seems reliable with the tradeoff I’m warming up to of making sure your os or the one your building on has all of the musl prerequisites manually installed. This varies by os.

This is the approach I’m trying to get sam team to accept https://github.com/awslabs/aws-lambda-builders/pull/174 (available someday maybe)

And one I’m experimenting with in the serverless framework https://github.com/softprops/serverless-rust/blob/master/README.md#-experimental-local-builds (available today)

The alternative is to build on a container that matches the lambda runtime. The tradeoff here is that assumes docker. Docker is most likely already present on many dev envs but comes with some limitations of what is preinstalled in that docker image https://github.com/softprops/lambda-rust. (available today)

From my experience, --target=x86_64-unknown-linux-musl is only half the battle because openssl is a bit of a bugger to configure and link. To handle that, you can add this to your Cargo.toml dependencies:

openssl = { version = "0.10", features = ["vendored"] }

The feature will download and compile openssl in your project’s target/ directory, with settings appropriate to the target you’re building for. The only possible complication is that you may need to also use the openssl-probe crate and call openssl_probe::init_ssl_cert_env_vars(); immediately in your main. Maybe this should be suggested in this project’s README?

@chumaumenze That makes sense. Trying to build crates with C/C++ dependencies isn’t trivial. Unfortunately, there isn’t anything that you can do at the moment. To properly resolve this issue, the runtime environment needs to be updated to use Amazon Linux 2, which has a significantly more recent glibc. I’m unable to share a date for when that work will be completed, but I’ll let you know when that update has launched.

@konstantinvlasenko Sorry, that’s my bad! Nothing to apologize for: I was curt in my previous message. You’ll need to build against the x86_64-unknown-linux-musl target, which statically links against the musl-libc. You can install musl-libc on Ubuntu/Debian/Amazon Linux; some of the instructions on https://wiki.debian.org/musl#Installation cover that. You’ll also need to add the x86_64-unknown-linux-musl target via Rustup: https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html.

All that being said, I am primarily a macOS user (with the occasional Amazon Linux usage), so I can’t really tell you how to install Musl on a Debian-based system. Personally, I build everything via a Docker image.

Hi everyone,

Having the same issue.

• My build environment is AWS EC2 instance (Amazon Linux 2 AMI 2.0.20190313 x86_64 HVM ebs).

• Lambda fails (after successful deployment) with the same error /var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.18’ not found (required by /var/task/bootstrap)

I’d actually close this issue and direct folks to provided.al2, all the MUSL tooling is not required anymore… unless there’s an edge usecase I’m not aware of nowadays?

I’m looking into building a docker container for rust and lambda that can work well with SAM CLI (and Apple Silicon trying to cross-compile ring) in https://github.com/aws/aws-sam-cli/issues/3132#issuecomment-901591206… so that local builds and sam local start-api works reliably for Rust.

@softprops , would it be better to replace

Since Lambda uses Amazon Linux, you’ll need to target your executable for an x86_64-linux platform.

with

Since Lambda uses Amazon Linux, you’ll need to target your executable for x86_64-unknown-linux-musl platform.

in the ReadMe (https://github.com/awslabs/aws-lambda-rust-runtime#aws-cli)?

I managed to get my Lambda going after targeting -musl.

(I also apologize if I over-explained anything to you!)