Summary
When building google-re2 from source using the setuptools fallback path (i.e. without Bazel / outside of GitHub Actions), the resulting _re2.so extension has unresolved abseil symbols. The wheel builds successfully (shared library builds allow undefined symbols by default), but crashes at import time:
>>> import re2
ImportError: /path/to/re2/_re2.cpython-312-x86_64-linux-gnu.so:
undefined symbol: _ZN4absl12lts_2025051218container_internal19GetRefForEmptyClassERNS1_12CommonFieldsE
Root cause
setup.py hardcodes libraries=['re2'] in the Extension definition. This works when linking against a shared libre2.so (the dynamic linker resolves the abseil dependency chain at runtime), but when libre2.a is the only available library (static build via CMake with -DBUILD_SHARED_LIBS=OFF), the linker never sees the abseil archives that libre2.a depends on.
Reproduction
- Build re2 and abseil-cpp from source as static libraries via CMake
- Install them to a prefix
- Build
google-re2 from the sdist using pip install --no-binary :all: google-re2 with CXXFLAGS=-I<prefix>/include and LDFLAGS=-L<prefix>/lib
- Attempt
import re2
Suggested fix
Use pkg-config --libs --static re2 to discover re2's transitive dependencies (abseil) when building from source, falling back to the current libraries=['re2'] when pkg-config is unavailable. The CMake install of re2 already produces re2.pc with Requires: absl_..., so pkg-config can resolve the full dependency chain.
This has no effect on the Bazel build path (GitHub Actions), and is backward-compatible: when pkg-config is not installed or re2.pc is absent, the behaviour is unchanged.
Context
We encountered this while building wheels for architectures where Bazel is not available (s390x, ppc64le), using CMake + setuptools as a fallback.
Summary
When building
google-re2from source using the setuptools fallback path (i.e. without Bazel / outside of GitHub Actions), the resulting_re2.soextension has unresolved abseil symbols. The wheel builds successfully (shared library builds allow undefined symbols by default), but crashes at import time:Root cause
setup.pyhardcodeslibraries=['re2']in the Extension definition. This works when linking against a sharedlibre2.so(the dynamic linker resolves the abseil dependency chain at runtime), but whenlibre2.ais the only available library (static build via CMake with-DBUILD_SHARED_LIBS=OFF), the linker never sees the abseil archives thatlibre2.adepends on.Reproduction
google-re2from the sdist usingpip install --no-binary :all: google-re2withCXXFLAGS=-I<prefix>/includeandLDFLAGS=-L<prefix>/libimport re2Suggested fix
Use
pkg-config --libs --static re2to discover re2's transitive dependencies (abseil) when building from source, falling back to the currentlibraries=['re2']when pkg-config is unavailable. The CMake install of re2 already producesre2.pcwithRequires: absl_..., so pkg-config can resolve the full dependency chain.This has no effect on the Bazel build path (GitHub Actions), and is backward-compatible: when pkg-config is not installed or
re2.pcis absent, the behaviour is unchanged.Context
We encountered this while building wheels for architectures where Bazel is not available (s390x, ppc64le), using CMake + setuptools as a fallback.