Revisit use of manylinux2010 to build wheel #78
Comments
|
I'm having trouble using scikit-build / cmake with Python 3.8. Even latest pip 19 refuses to install the manylinux2010 wheel and tries to install a sdist. For python <3.8, pip installs a manylinux1 wheel from previous cmake version (3.13.3). And that works since |
|
@JFCR, fyi, I provide manylinux1 wheels for boost-histogram, which requires C++14, and is built with https://github.com/scikit-hep/azure-wheel-helpers and GCC 9.2 from https://github.com/scikit-hep/manylinuxgcc (docker container). It wouldn't be valid to link to from another manylinux1 wheel unless it also was built with GCC 9, but no one is linking to CMake, so something like that might be an option for a manylinux1 compliant wheel. Just a thought. Edit: This appears to be a kernel system call missing and a built-in libuv problem, never mind. In that case, can't a system libUV from CentOS 5 be bundled in? |
Yes, I just tested that approach. Building against libuv 1.23.0 (prior libuv/libuv@f43c663) and it seems to work well. I will create new releases of existing cmake wheels (with |
As discussed in [1], starting with CMake 3.14.0, version of libuv bundled in CMake doesn't support being built with manylinux1. This commit explicitly downloads an older version of libuv that can be built on system with older kernel. To avoid link error like the following, -lrt linker flag is specified: /work/libuv-install/lib64/libuv_a.a(linux-core.c.o): In function `uv__hrtime': linux-core.c:(.text+0xb58): undefined reference to `clock_getres' linux-core.c:(.text+0xbab): undefined reference to `clock_gettime' /work/libuv-install/lib64/libuv_a.a(linux-core.c.o): In function `uv_uptime': linux-core.c:(.text+0xd91): undefined reference to `clock_gettime' linux-core.c:(.text+0xda7): undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status See #78 [1] https://gitlab.kitware.com/cmake/cmake/issues/19311
This commit creates a new release of CMake 3.14.3 wheels compatible with manylinux1. See #78
|
For future reference, here are the tags for new release of CMake wheels compatible |
Background:
We started building the cmake wheel using manylinux2010 because, the latest version of cmake couldn't be built using manylinux1.
At first, only providing manylinux2010 wheel for the latest cmake was preventing
pip install cmakedone from a manylinux1 environment from downloading the latest wheel available for that platform, indeed, by default, pip prefer building the latest sdist instead of downloading the latest wheel for that platform. This is discussed in pypa/pip#6550.For an example of project that faced that problem, see equinor/dlisio#116 and #76
To address, this, the sdist associated with cmake 3.14.3 and 3.14.4 were removed from pypi (note that sdist of 3.13.3 was also removed but this was not strictly required).
Next step
As suggested in https://gitlab.kitware.com/cmake/cmake/issues/19311, we could look into building cmake against a version of an older libuv library built on manylinux1.
The text was updated successfully, but these errors were encountered: