From 3a9f681ccecc9501c7afca825fc91f1f789d9226 Mon Sep 17 00:00:00 2001 From: kukushking Date: Tue, 7 Jul 2026 18:52:24 +0100 Subject: [PATCH] fix(lambda): use PyPI wheels for numpy/pandas on AL2023 layer builds (#3393) Building numpy/pandas from source without pinning the build-time numpy to the runtime numpy produces a pandas binary linked against a numpy ABI that doesn't match the numpy 2.5.x shipped alongside it, causing SIGSEGV on datetime64 construction paths (e.g. df["t"] = datetime.now(), pd.to_datetime(...)). AL2023 has glibc 2.34, which satisfies the manylinux_2_28 tag PyPI ships numpy/pandas wheels under, so drop the source-build override on that Dockerfile and gate the flag in build-lambda-layer.sh on /etc/os-release. AL2 (glibc 2.26) can't load manylinux_2_28 and its older numpy 2.4.x source build is unaffected, so keep source builds there. Verified in a public.ecr.aws/lambda/python:3.12 container that the segfault reproduces without the fix and disappears with it; AL2 py3.11 source-built numpy 2.4.6 + pandas 3.0.3 continue to work. --- building/lambda/Dockerfile.al2023 | 11 +++++++---- building/lambda/build-lambda-layer.sh | 13 ++++++++++++- 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/building/lambda/Dockerfile.al2023 b/building/lambda/Dockerfile.al2023 index 121d1cab6..b589d23eb 100644 --- a/building/lambda/Dockerfile.al2023 +++ b/building/lambda/Dockerfile.al2023 @@ -33,11 +33,14 @@ RUN pip3 install --upgrade cmake==3.31.6 # libcst (used for build-time stub docstring extraction) are required. RUN pip3 install --upgrade six "cython>=3.1" hypothesis uv build scikit-build-core "libcst>=1.8.6" -ENV PIP_NO_BINARY="numpy,pandas" +# AL2023 has glibc 2.34, which satisfies the manylinux_2_28 tag that PyPI +# ships numpy/pandas wheels under. Building numpy/pandas from source here +# without locking the build-time numpy to the runtime numpy produces an +# ABI-mismatched pandas binary that SIGSEGVs on datetime64 construction +# (issue #3393). The AL2-based Dockerfile still forces source builds because +# AL2's glibc 2.26 can't load manylinux_2_28 wheels. ENV UV_PROJECT_ENVIRONMENT="/var/lang" -RUN uv sync --frozen --inexact --no-dev --no-install-project \ - --no-binary-package numpy \ - --no-binary-package pandas +RUN uv sync --frozen --inexact --no-dev --no-install-project RUN rm -f pyproject.toml uv.lock diff --git a/building/lambda/build-lambda-layer.sh b/building/lambda/build-lambda-layer.sh index 17b96731f..673ab6240 100755 --- a/building/lambda/build-lambda-layer.sh +++ b/building/lambda/build-lambda-layer.sh @@ -89,7 +89,18 @@ popd pushd /aws-sdk-pandas -pip3 install . --no-binary numpy,pandas --find-links="${PYARROW_WHEEL_DIR}" -t ./python ".[redshift,mysql,postgres,gremlin,opensearch,openpyxl]" "pyarrow==${ARROW_VERSION}" +# Building numpy/pandas from source on AL2023 without pinning the build-time +# numpy to the runtime numpy produces an ABI-mismatched pandas binary that +# SIGSEGVs on datetime64 construction (issue #3393). AL2023's glibc 2.34 +# satisfies the manylinux_2_28 tag that PyPI ships numpy/pandas wheels under, +# so use those wheels. AL2 (glibc 2.26) is too old to load manylinux_2_28, +# so keep forcing source builds there. +NO_BINARY_FLAG="" +if [ -r /etc/os-release ] && grep -q '^VERSION_ID="2"' /etc/os-release; then + NO_BINARY_FLAG="--no-binary numpy,pandas" +fi + +pip3 install . ${NO_BINARY_FLAG} --find-links="${PYARROW_WHEEL_DIR}" -t ./python ".[redshift,mysql,postgres,gremlin,opensearch,openpyxl]" "pyarrow==${ARROW_VERSION}" # CVE-2026-41066: upgrade lxml past redshift-connector's <=6.0.2 cap. # pyproject.toml's [tool.uv] override-dependencies only applies to uv, not pip,