BUG: Getting error message "libexpat.so.1: cannot open shared object file: No such file or directory" with python 3.13

[f-skold]

Hi, I wanted to upgrade the deployment/aws/lambda to use 3.12 or 3.13 so I can try it with Lambda SnapStart (https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)

#1106 , here is a branch /pull request with the stuff that seemed to work:

• I went ahead and bumped the CDK version to the current one 2.185.0 / (2.1005.0).
• Used a newer python version in dockerfiles/Dockerfile

f-skold@5d64110

I this change, I try to use AWS image for python 3.13, it is using AWS Linux 2023 (see https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)
they have changed package manager from yum to dnf.

When running this in a lambda, I get this error message:

[ERROR] Runtime.ImportModuleError: Unable to import module 'handler':
libexpat.so.1: cannot open shared object file: No such file or directory
Traceback (most recent call last):

Here is alist of what packages exists in the new AWS Linux: https://docs.aws.amazon.com/linux/al2023/release-notes/all-packages-AL2023.6.html

Can you help me investigate this:
What is the error here, is it AWS Linux 2023 that do not ship libexpat1.so?
How can I see what in python is causing this problem? In my CloudWatch logs, the message is cut after the third line ("Traceback (most recent call last):")
Or is it some python package that wants to use libexpat1.so when it could use libexpat 2 instead?

Regards, Fredrik

[vincentsarago]

ref rasterio/rasterio-wheels#136 developmentseed/titiler-md-demo#3

[f-skold]

Hmm, actually, it seems like there is a file libexpat.so.1
So why cannot rasterio make use of that file?

bash-5.2# ls -l /lib64/libexpat.so*
lrwxrwxrwx 1 root root     17 Dec 16 23:10 /lib64/libexpat.so -> libexpat.so.1.9.3
lrwxrwxrwx 1 root root     17 Dec 16 23:10 /lib64/libexpat.so.1 -> libexpat.so.1.9.3
-rwxr-xr-x 1 root root 199136 Dec 16 23:10 /lib64/libexpat.so.1.9.3

bash-5.2# file /lib64/libexpat.so.1.9.3
/lib64/libexpat.so.1.9.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f8a4f149ba96773507e41b4546f9c8b0c64c0762, stripped

[vincentsarago]

@f-skold I'm sorry I do not have time to work on this at the moment because of project work.

I would be careful about what is in the docker image and what is within the lambda environment. I found couple time that they are not the same.

[f-skold]

@vincentsarago, sure. I am quite happy about what is provided already, it is just frustrating that I cannot find a path forward.

Thinking out loud if you can give any hints:

• Do you have any idea on how I can see the full stack trace instead of the truncated one I get today?
• Should I be able to reproduce this locally?

Yes, since there is one thing that is lambda running any docker image, and there is also a python 3.12 runtime that the cdk/app.py says that we currently are using.
But it is quite a blurry/confusing if we use a Dockerfile to build something that is more of a "layer" that is what the lambda is actually executing.