GLIBC and AWS Lambda

[deftomat]

We just tried to use libvips generated by ./build.sh 8.7.4 linux-x64 in AWS lambda and Sharp is failing with the following error:

Something went wrong installing the "sharp" module

/lib64/libc.so.6: version `GLIBC_2.18' not found (required by /opt/sharp/build/Release/../../vendor/lib/librsvg-2.so.2)

- Remove the "node_modules/sharp" directory, run "npm install" and look for errors
- Consult the installation documentation at https://sharp.pixelplumbing.com/en/stable/install/
- Search for this error at https://github.com/lovell/sharp/issues

Looks like commit acd9d57 introduces a dependency on GLIBC 2.19. However, AWS Lambda environment has v2.17.

[lovell]

Hi, is this with Node 8 only or both Node 8 and 10 (Amazon Linux 2)?

https://aws.amazon.com/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/

[lovell]

"Amazon Linux 2 comes with GCC 7.3, Glibc 2.26, and Binutils 2.29.1"
https://aws.amazon.com/amazon-linux-2/release-notes/

It looks like this problem is only going to occur on the deprecated Lambda runtime environment that reaches end-of-life on the 29th July.

[deftomat]

We are using node 8 lambdas. Not sure about v10

[deftomat]

Anyway, I didn't know that AWS already supports v10. Thank you for letting me know. I'm going to try it with v10. 😉

[lovell]

This error can also be seen on RHEL 7 and its derivatives e.g. CentOS 7, which use glibc 2.17.

It looks like the rust toolchain used by librsvg takes advantage of features of glibc 2.18 - see rust-lang/rust#36826

This means the prebuilt binaries will drop support for RHEL 7 from sharp v0.23.0+.

RHEL 8, upon which Amazon Linux 2 is based, works correctly.

[kleisauke]

Isn't Amazon Linux 2 based on RHEL 7? Also note that CentOS 8 has not yet been released (I noticed that it was mentioned in this commit).

Perhaps we could try to build the Linux binaries on CentOS 7 (glibc 2.17) to make sure they are compatible on RHEL 7, Amazon Linux 2 and possibly on Debian 7 as well.

[kleisauke]

Also, could the musl docker image be based on Alpine 3.10 (musl libc 1.1.22)? I guess musl libc 1.1.20 and 1.1.22 are binary compatible.

The latest versions of musl libc have several threads and stack size improvements (for e.g. the default thread stack size has been increased from 80k to 128k, which may help libvips/libvips#1287).

As a side note,
If you are going to update Fontconfig to 2.13.91, you can also remove the UUID dependency (which was added with commit e67bfd6), see:
https://cgit.freedesktop.org/fontconfig/commit/?id=c4324f54ee16e648ba91f3e9c66af13ab3b1754c
Hopefully Fontconfig will soon be updated within Homebrew as well to fix lovell/package-libvips-darwin#3 (comment).

[lovell]

Amazon Linux 2 provides glibc 2.26, which makes it more like Fedora 27 in that respect.

I didn't realise CentOS 8 was still being built. If we can create a CentOS 7 based container able to run the existing lin.sh script then that would provide support for glibc 2.17+.

Thanks for the tip about removing uuid - I've done this in ca94439

[kleisauke]

I tried a CentOS 7 based container and it seems to build (I still have to test the binaries). See commit kleisauke@e2f9819.

Also, it seems Fontconfig 2.13.91 is a preview release (Homebrew didn't want to update to this version), perhaps we need to pinpoint it to 2.13.1.

[lovell]

@kleisauke Thank you! I borrowed most of your CentOS 7 work in commit 4080762 and used it to create the binaries for libvips v8.8.1 (as used by sharp v0.23.0).