Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Bulk copy fails on RHEL 8 / aarch64 with mssql-python 1.8.0: bundled `mssql_py_core` requires libssl.so.3 and GLIBC ≥ 2.34, but wheel is tagged `manylinux_2_28_aarch64`

Geschlossen
  • Stimmt etwas nicht?
#619 4 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

@bewithgaurav arbeitet bereits daran.

Seit 03.6.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

area: packaging-platform bug inADO triage done

Summary

On a fresh RHEL 8.10 aarch64 host, mssql-python==1.8.0 installs cleanly from PyPI, but invoking bulk copy raises:

ImportError: Bulk copy requires the mssql_py_core library which is not available. This is an unexpected error.

This matches the report at https://www.reddit.com/r/SQLServer/comments/1trcsy7/comment/op95k4b/.

After investigation, the underlying cause appears to be that the bundled mssql_py_core extension shipped inside the manylinux_2_28_aarch64 wheel has runtime requirements (libssl.so.3, libcrypto.so.3, GLIBC_2.34) that exceed what the manylinux_2_28 tag promises (RHEL 8 / glibc 2.28 / OpenSSL 1.1). I may be wrong about the exact build-time root cause, but the loader-level symptoms are reproducible and shown below.

Environment

  • OS: Red Hat Enterprise Linux release 8.10 (Ootpa)
  • Arch: aarch64
  • Python: 3.11.x (from python3.11 RHEL AppStream module)
  • Install: pip install mssql-python==1.8.0 in a clean venv
  • glibc on host: 2.28
  • OpenSSL on host: 1.1.1k (no libssl.so.3 present)

Reproduction

sudo dnf install -y python3.11 python3.11-pip libtool-ltdl krb5-libs
python3.11 -m venv ~/mssqltest
source ~/mssqltest/bin/activate
pip install --upgrade pip
pip install mssql-python==1.8.0
python -c "import mssql_py_core"

Observations

1. mssql_py_core is in fact bundled (contrary to what the error message implies)

The mssql-python 1.8.0 wheel installs mssql_py_core as a sibling top-level package. From mssql_python-1.8.0.dist-info/RECORD:

mssql_py_core/__init__.py,sha256=dWpohDsyIDgFPp8wCLZEDeEsk_Kn4vL8Bp83Ptn-jNg,135
mssql_py_core/__pycache__/__init__.cpython-311.pyc,,
mssql_py_core/mssql_py_core.cpython-311-aarch64-linux-gnu.so,sha256=…,8225592

So this is not a missing-package problem — the file is on disk.

2. The real failure is at dynamic-link time
$ python -c "import mssql_py_core"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File ".../site-packages/mssql_py_core/__init__.py", line 1, in <module>
    from .mssql_py_core import *
ImportError: libssl.so.3: cannot open shared object file: No such file or directory

$ ldd .../mssql_py_core/mssql_py_core.cpython-311-aarch64-linux-gnu.so 2>&1 | grep -E 'ssl|crypto|not found'
        /lib64/libm.so.6: version `GLIBC_2.29' not found (required by …mssql_py_core…)
        /lib64/libc.so.6: version `GLIBC_2.32' not found (required by …mssql_py_core…)
        /lib64/libc.so.6: version `GLIBC_2.33' not found (required by …mssql_py_core…)
        /lib64/libc.so.6: version `GLIBC_2.34' not found (required by …mssql_py_core…)
        libssl.so.3 => not found
        libcrypto.so.3 => not found

Host versions for comparison:

$ ls /usr/lib64/libssl* /usr/lib64/libcrypto*
/usr/lib64/libcrypto.so.1.1     /usr/lib64/libssl.so.1.1
/usr/lib64/libcrypto.so.1.1.1k  /usr/lib64/libssl.so.1.1.1k
/usr/lib64/libssl3.so   # this is NSS, not OpenSSL 3 — unrelated despite the name
3. Wheel tag vs. actual requirements

The installed wheel is mssql_python-1.8.0-cp311-cp311-manylinux_2_28_aarch64.whl (from https://pypi.org/pypi/mssql-python/1.8.0/json). The manylinux_2_28 profile corresponds to glibc 2.28 / RHEL 8 / UBI 8 (PEP 600). RHEL 8 also ships OpenSSL 1.1, not OpenSSL 3. The bundled mssql_py_core .so requires symbols newer than that profile allows, so pip happily installs a wheel that cannot load on the platform it claims to support.

That said, I haven't run auditwheel show against the wheel myself, so it's possible the higher requirement comes from a different .so in the bundle and I've misattributed it. The loader error above is what users will hit either way.

4. Error-message UX (minor, separate)

In mssql_python/cursor.py (1.8.0), the bulk-copy path does:

try:
    import mssql_py_core
except ImportError as exc:
    logger.error("_bulkcopy: Failed to import mssql_py_core module")
    raise ImportError(
        "Bulk copy requires the mssql_py_core library which is not available. "
        "This is an unexpected error. "
    ) from exc

The from exc does preserve the real libssl.so.3: cannot open shared object file in the chained traceback, but the top-line message ("not available", "unexpected error") leads users to think the package is missing rather than failing to load. Surfacing str(exc) in the re-raised message would have saved both the Reddit user and me a fair amount of guessing.

Expected behavior

One of:

  • The aarch64 wheel content is rebuilt against the manylinux_2_28 sysroot (glibc 2.28, OpenSSL 1.1) so it actually loads on the platforms the tag advertises, or
  • The wheel is re-tagged (e.g. manylinux_2_34_aarch64) so pip declines to install it on RHEL 8 / UBI 8 / Amazon Linux 2 and falls back to a source install or an error users can act on.

It would also be worth checking the manylinux_2_28_x86_64 wheel against the same criteria — I only verified aarch64 on this host, so I can't say whether x86_64 has the same mismatch.

Suggestions (lower priority)

  • Include str(exc) in the re-raised ImportError in cursor.py, so the missing .so dependency surfaces in the top-line message.
  • Consider adding auditwheel show / repair to the release pipeline for the Linux wheels to catch tag/content mismatches before publish.

Sources

Vorherrschende Sprache
Python
Sterne
478
Forks
62
Ø Merge
3 T. 19 Min.
Gemergte PRs (30 T.)
28

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/mssql-python

Alle Issues in microsoft/mssql-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.