Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manylinux2010 behaviour understand #187

Closed
Czaki opened this issue Nov 3, 2019 · 6 comments
Closed

manylinux2010 behaviour understand #187

Czaki opened this issue Nov 3, 2019 · 6 comments

Comments

@Czaki
Copy link
Contributor

Czaki commented Nov 3, 2019

I have few questions about introducing manylinux210 to cibuildwheel.

  1. Why manylinux2010 build both manylinux1 and manylinux2010 wheels (Why to do this if something can be compiled to manylinux1 then is no ned for manylix2010 ??)

  2. What is some extensions need c++14 or c++17. The manylinux2010 container has proper compilers, but it may use some features not available for old images. (??)

@Czaki Czaki changed the title manylinux2010 behaviour unserstand manylinux2010 behaviour understand Nov 3, 2019
@YannickJadoul
Copy link
Member

@Czaki

  1. There's been a veeeeery long discussion in Adding support for building manylinux2010 wheels - alternative #155 and Adding support for building manylinux2010 wheels #135. Short answer: manylinux1 and manylinux2010 are standards on what versions of libraries can be used (glibc, etc); see PEP 513 and PEP 571, and sometimes a wheel compiled on the manylinux2010 image is still manylinux1. We've discussed this at length, and so have the folks from manylinux and auditwheel, and the main conclusion was that it's fine to return multiple wheels.
  2. I don't understand? manylinux2010 has newer versions of compilers, so you should be able to use newer C++ standards. Apart from that, if you want to use even newer compiler versions that require a post-manylinux2010 standard library, the same principle probably goes as for manylinux1: Cannot build C++14 in docker images manylinux#118

@Czaki
Copy link
Contributor Author

Czaki commented Nov 3, 2019

So current solution, if it is possible build manylinux1 and manylinux2010, and if some new things not supported by manylinux1 is needed then only manylinux2010 wheel is produced?

@YannickJadoul
Copy link
Member

Well, just one wheel is built. And if that happens to be manylinux1 compatible, auditwheel wil give you two copies, one tagged with manylinux1 and the other with manylinux2010.

And every manylinux1 wheel is also compatible with manylinux2010, so if you still need to be sure you have manylinux1, you can say CIBW_MANYLINUX_IMAGE="manylinux1".

@Czaki
Copy link
Contributor Author

Czaki commented Nov 3, 2019

Ok. Thanks. My question is connected with question "What I need to upload to pypi?". "If there is any advantage of upload both wheels to pypi?"

Now I have bases to think about this.

@YannickJadoul
Copy link
Member

That's still not completely clear to me. Do read the further discussions we had on keeping 1 or 2 wheels, and the link to the pypa/manylinux discussion in there, where I asked the same question and got an answer: pypa/manylinux#179 (comment)

@YannickJadoul
Copy link
Member

Is that OK with you? Can we close this issue and get the issues counter one down again? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants