Python 3.8 wheel linked against newer libc

[LordAro]

Got a failure with py38 (py36 & py37 are fine)

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.4',
'GLIBC_2.2.5', 'GLIBC_2.14'}

I'm not sure what's happened here, somehow it's ended up linked against a newer/incorrect libc.so ?

Full results here: https://github.com/LordAro/nml/runs/553326716?check_suite_focus=true

What's gone wrong?

[RalfG]

There are some libraries used for the Python 3.8 wheel which cannot be used in the manylinux2010 specification. Auditwheel suggests to make a manylinux2014 version of the wheel. Can you try the following version of the action, with the @v0.2.2-manylinux2014_x86_64 suffix?

    - name: Build manylinux Python wheels
      uses: RalfG/python-wheels-manylinux-build@v0.2.2-manylinux2014_x86_64
      with:
        python-versions: 'cp36-cp36m cp37-cp37m cp38-cp38'
        build-requirements: 'ply Pillow'  # Don't think there's another way of passing these in
      if: startsWith(matrix.os, 'ubuntu')

[LordAro]

I imagine that would work yes, but why is it necessary? There's no reason why I shouldn't be able to have py38 working with manylinux2010 (or indeed manylinux1, though it's getting increasingly difficult to build of course)

[LordAro]

I have (for other unrelated reasons) built a Python3.8 install for CentOS/RH6, so I know it's possible. What exactly is the problem library?

[RalfG]

This is the message that auditwheel returns:

+ auditwheel show /github/workspace/wheelhouse/nml_test-0.5.0a4-cp38-cp38-linux_x86_64.whl

nml_test-0.5.0a4-cp38-cp38-linux_x86_64.whl is consistent with the
following platform tag: "manylinux2014_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.4',
'GLIBC_2.2.5', 'GLIBC_2.14'}

This constrains the platform tag to "manylinux2014_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

It seems that the libc versions are not compatible with manylinux < 2014; auditwheel recommends building with manylinux2014_x86_64.

If you do this for all Python versions, and some wheels (e.g. Python 3.6, 3.7) are eligible for manylinux2010 or even manylinux1, auditwheel will mark them as such. So in your current workflow they would be uploaded to PyPI as e.g. manylinux1, even though they were build on manylinux2014.

[TkTech]

I had the exact same issue. In hindsight, the problem was obvious and was fixed by https://github.com/TkTech/pysimdjson/issues/43.

Install the host python after you build all your wheels. Somehow it's using parts of the host python 3.8 instead of the manylinux python 3.8. There's probably an isolation issue in this action.

[RalfG]

@TkTech, Could it be that running pip install -e '.[dev]' (which isn't really necessary), during the Install dependencies step, left over some pip build artefacts in the working directory?