Hardcoded RPATHs for libsqlite3 in manylinux2014 Images

[AndrewAsseily]

Beginning with the 2025.02.08-1 tags, we noticed that manylinux2014 images for aarch64 and x86_64 have hardcoded RPATHs for libsqlite3. This is causing issues for users who check for invalid RPATHs using the standard tool check-rpaths: aws/aws-cli#9330
For context, the AWS CLI team builds Linux installers for AWS CLI v2 using manylinux2014 as base images and package necessary shared libraries, including libsqlite3. Since our Linux installers are used across diverse Linux environments, we can’t assume that /usr/local/lib/libsqlite3.so is always a valid RPATH.

To reproduce:

Pull the manylinux2014 image:
docker run --rm -it quay.io/pypa/manylinux2014_x86_64 bash
Check the RPATH of libsqlite3:
readelf -d /usr/local/lib/libsqlite3.so|grep RPATH

Observe that the output includes a hardcoded RPATH:
0x000000000000000f (RPATH) Library rpath: [/usr/local/lib]

We’re wondering if hardcoding the RPATH was intentional. If it was, we’d appreciate context to help us determine long-term solutions for our users, and any future plans to extend this to other shared libraries. If it wasn’t intentional, we were wondering if it could be patched out when building manylinux2014 images so all consumers can benefit. It’s not immediately obvious to us if this change is coming from sqlite, gcc, or manylinux2014 build configurations.

Thank you,

[mayeut]

If it starts with 2025.02.08-1 tag then it's likely related to a sqlite3 update where they changed the default values in there build system.
The only goal of manylinux images is to help build wheels. Building a portable python distribution is a non-goal of this repo so relying on the behavior of this non-goal is undefined.

Short term, if you have a patch to propose, it'll be reviewed.
Mid/long term, for portable distributions of python, I'd recommend looking at https://github.com/astral-sh/python-build-standalone which is meant to be a redistributable Python distribution.