AWS Lambda Ruby 2.7 Pg Gem LibLDAP Error

We’ve been upgrading our Lambda functions to use the Ruby 2.7 runtime on AWS Lambda and some of the functions in our projects ran into unexpected issues. In this article we’re going to take a brief step back to give context to the issue we experienced and walk you through our investigation and resolution.

Ruby Gems with Native Extensions in AWS Lambda

Previously we had to jump through some hoops to get gems with native extensions working in Lambda as it requires the included binaries to be built in the same environment. Two typical use cases in our projects that required us to jump through these hoops are the excellent Pg and Nokogiri gems.

If you’re reading this article we’re going to assume you are familiar with the native extensions issue in AWS Lambda with Ruby. If you are not familiar; the short version is that you need to emulate the AWS Lambda environment with LambCI and Docker on a development machine or build server. This allows you to compile your native dependencies in a docker container that will be compatible when deployed to a Ruby Lambda function.

The LibLDAP Pg Gem Error in our Lambda Ruby Functions

After upgrading our Serverless project to Ruby 2.7 and switching to the ruby2.7 runtime we were greeted with this unexpected error message when executing a function that was leveraging the postgres gem: cannot open shared object file: No such file or directory - /var/task/vendor/bundle/ruby/2.7.0/gems/pg-1.2.3/lib/

This left us scratching our heads for a while as we were bundling with our Lambda Ruby function, which is all we previously needed using the ruby2.5 runtime. Why was our function complaining about a library for LDAP anyway?

As it turns out this is a shared library that is indeed needed by the native pg dependencies. We confirmed this by using the ldd utility to list dynamic dependencies within our LambCI build container:

bash-4.2# ldd (0x00007ffe34ff1000) => /var/lang/lib/ (0x00007f6805888000) => /usr/lib64/ (0x00007f680565a000) => /usr/lib64/ (0x00007f680531a000) => /usr/lib64/ (0x00007f6804f6f000) => /usr/lib64/ (0x00007f6804d5a000) => /usr/lib64/ (0x00007f6804b3c000) => /usr/lib64/ (0x00007f6804934000) => /usr/lib64/ (0x00007f6804730000) => /usr/lib64/ (0x00007f68044f9000)
/lib64/ (0x00007f6806068000) => /usr/lib64/ (0x00007f680428a000) => /usr/lib64/ (0x00007f6803e35000) => /usr/lib64/ (0x00007f6803b51000) => /usr/lib64/ (0x00007f680394d000) => /usr/lib64/ (0x00007f6803701000) => /usr/lib64/ (0x00007f68034a3000) => /usr/lib64/ (0x00007f6803272000) => /usr/lib64/ (0x00007f6803063000) => /usr/lib64/ (0x00007f6802e5f000) => /usr/lib64/ (0x00007f6802c49000) => /usr/lib64/ (0x00007f6802a3a000) => /usr/lib64/ (0x00007f680281d000) => /usr/lib64/ (0x00007f68025c7000) => /usr/lib64/ (0x00007f68023a1000) => /usr/lib64/ (0x00007f680207f000) => /usr/lib64/ (0x00007f6801e50000) => /usr/lib64/ (0x00007f6801c4c000) => /usr/lib64/ (0x00007f6801a47000) => /usr/lib64/ (0x00007f680180b000) => /usr/lib64/ (0x00007f68015e4000) => /usr/lib64/ (0x00007f6801380000)

But why was the library missing in our Lambda, this should be included in /usr/lib64?

We started to dig into the Lambda runtimes and discovered a much larger change we were not initially aware of moving from Ruby 2.5 to Ruby 2.7 as seen below:

AWS Lambda Ruby Runtimes

Name Identifier AWS SDK for Ruby Operating System
Ruby 2.7 ruby2.7 3.0.1 Amazon Linux 2
Ruby 2.5 ruby2.5 3.0.1 Amazon Linux

The ruby2.7 runtime is actually running on Amazon Linux 2! With the move to Amazon Linux 2 there are significantly less bundled libraries available by default as can be seen in these two gists:

Cross referencing our dynamic dependency results from above, we determined the following shared libs needed to be bundled with in our function:

After updating our Makefile to copy these shared libs to our task lib directory, our world is no longer on fire and we are back to working as expected with the pg gem in our AWS Lambda Ruby functions.

Getting the Ruby Postgres Pg Gem working again in AWS Lambda

We have included our Dockerfile and Makefile below that builds our LambCI docker container and copies over our required Postgres dependencies before deploying. We are assuming for brevity that you have an established process in place to deploy your Ruby Lambda function. We leverage Serverless in our all AWS Lambda projects, which handles the heavy lifting of deployments for us.


FROM lambci/lambda:build-ruby2.7

RUN yum install -y postgresql postgresql-devel
RUN gem update bundler

CMD "/bin/bash"


        docker build -t northsail/sls-ruby2.7-builder:latest .

        make image
        docker run --rm -it -v $$PWD:/var/task -w /var/task northsail/sls-ruby2.7-builder:latest make _install

        bundle config --local silence_root_warning true
        bundle install --path vendor/bundle --clean
        mkdir -p /var/task/lib
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/
        cp -a /usr/lib64/ /var/task/lib/

Could you benefit from a dependable Ruby development partner?

Learn about our ruby on rails development services.

Back to articles

Subscribe to thoughts and insights from Nothsail

We’ll send you an email when we have something new and interesting to share.

Our crew won’t spam you or sell your email address and you can unsubscribe at any time.

Back to top