2

I'm trying to get a Lambda happy version of XPDF's pdftohtml to work but am having no luck.

So far the following has been tried:

  • Created Docker container running the latest amazonlinux image
  • I've copied the source code into this container and ran:

    yum install cmake, gcc, gcc-c++, freetype-devel

  • Compiling the code with cmake produces a binary which executes perfectly in the container which should be the same OS and environment as Lambda.
  • I've verified the version of libc.so.6 as 2.26 within the container.
  • I've copied this into my AWS zip folder and included the following dependencies in a lib folder ready to upload:

    libfreetype.so.6.10.0, libpng15.so.15, libstdc++.so.6.0.24

  • These dependencies are copied directly from the container used to compile the code.

  • Python function then connects these via

    os.environ.update(dict(LD_LIBRARY_PATH='/var/task/lib'))

  • At the end of this, I run the function and get the following error code:

    /var/task/pdftohtml: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /var/task/lib/libstdc++.so.6)

I've no idea where the GLIBC_2.18 comes from as this version isn't present in the container used to compile it.

Really stumped but keen to get it finished as it would produce a lightweight binary perfect for a Lambda function!

Where am I going wrong?

EDIT

SOLVED - see the comments below. There are two versions of AWS Linux and Lambda runs this version

I ran in an EC2 instance as one of the commenters suggested. Whilst the libstdc++.so.6.24 looked to be the right version, as it was itself compiled with a different GLIBC version, it throws an error. Compiling in EC2 from the source code worked fine. The other trick was making sure the CXX_FLAGS included -std=c++11. Thanks to those who contributed to help me solve this!

lawson
  • 377
  • 1
  • 13
  • If you have followed the official instructions (such as using `gcc64`), then this sounds something that's worth a support ticket. It looks like an issue with their environment. – Florian Weimer Feb 15 '19 at 21:03

1 Answers1

1

I've no idea where the GLIBC_2.18 comes from as this version isn't present in the container used to compile it.

I think you don't understand symbol version dependencies (see here).

The error message is telling you that your libstdc++.so.6 was built against GLIBC-2.18 or newer, and you are running against GLIBC-2.17 or older.

Where am I going wrong?

Your build environment is targeting something much newer than what your deployment environment contains.

You need to either find a built environment that matches your deployment target, or you need to change your deployment target to be not older than your build environment.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Hi @Employed Russian - thanks for your answer and your input. My confusion lies in the fact that the build environment and deployment environment are the same - both the docker image for the build and the AWS Lambda deployment environment run the latest version of amazon linux. To test I'm not inadvertently upgrading a dependencies as part of the build, I've compiled the binary in one before spinning up a clean image and copying in the binary plus a handful of required .so files (**not** including libstdc++ or libc) and it runs perfectly. As soon as I deploy on AWS Lambda, I hit the problems – lawson Feb 21 '19 at 21:20
  • @lawson just a thought, but according to https://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html the Lambda environment is running amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2. It is not the latest Amazon Linux version (which is Amazon Linux 2). Not sure if you are accidentally running the docker image (amazonlinux points to the Amazon Linux 2, so you need to use amazonlinux:1 for the docker image that is Amazon Linux 1). Also, maybe compile in an EC2 instance running the exact image in the Lambda documentation? – Kai Yao Feb 22 '19 at 09:38
  • @KaiYao - you're absolutely right! I hadn't realised there was a different version - Doh! I compiled in an EC2 instance and now understand what EmployedRussian meant. The version of glibc in the old amazonlinux is 2.17 so the version of libstdc++.so.6 would have been compiled with a different glib than in the newer amazonlinux. If anyone reads this and is wanting to do the same, change CMakeLists.txt to run a compatible version of CMake ( < 2.9 ) and set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11"). – lawson Feb 25 '19 at 16:48