# The next manylinux specification

**URL:** https://discuss.python.org/t/the-next-manylinux-specification/1043
**Category:** Packaging
**Created:** [March 22, 2019, 7:59pm UTC](https://discuss.python.org/t/the-next-manylinux-specification/1043 "2019-03-22T19:59:25Z")
**Posts on this page:** 1
**Showing post:** 40

<div class="post-metadata">

### Author: ![njs](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/njs/32/204_2.png) [@njs](https://discuss.python.org/u/njs)
#### Post date: [March 28, 2019, 10:36pm UTC](https://discuss.python.org/t/the-next-manylinux-specification/1043/40 "2019-03-28T22:36:53Z")

</div>

> [@dustin](#):
>
> satisfying maintainers desire to determine if they can build compatible distributions without just saying “auditwheel will tell you if you did it right or not”?

Everything I’m proposing is about standardizing the things we’re already doing, and that we know work. Auditwheel is _already_ the most accurate, useful, and up-to-date record of how to build compatible wheels on Linux, because it’s what maintainers actually use. I’m pretty sure there have been fixes to the spec in auditwheel that we forgot to merge back into PEP 513, or where the PEP 513 update came later as an afterthought.

> [@dustin](#):
>
> This sounds like we’re just pushing the “specification” into auditwheel, where it would be a) more difficult for interested parties to determine what the rules are, exactly, and b) more work for auditwheel maintainers (who are few and far between). It just wouldn’t require a PEP.

In practice, the specification already lives in auditwheel, so there’s no additional maintenance burden. It’s true that reading the rules would require reading some code, but in practice (a) the code is guaranteed to be accurate and up to date, unlike the PEP, (b) you’re still better off than on Windows or macOS, where the rules aren’t written down at all…

> [@jjhelmus](#):
>
> For a specific example, Debian 8 (Jessie) ships with glibc 2.19 and gcc 4.9.2. Wheels produced by a system running this distribution would be labeled with the `manylinux_glibc_2_19_x86_64` tag and the gcc toolchain would include symbols with maximum versions of [CXXABI\_1.3.8 and GLIBCXX\_3.4.20](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html). Ubuntu 14.04 (Trusty) also ships with glibc 2.19 but the gcc version is 4.8.2 which contains maximum version symbols of CXXABI\_1.3.7 and GLIBCXX\_3.4.18.

A `manylinux_glibc_2_19_x86_64` tag would mean that the wheel is compatible with _all_ mainstream distros using glibc 2.19+ on x86-64.

Ubuntu 14.04 is a mainstream distro using glibc 2.19+ on x86-64.

Therefore, to get a `manylinux_glibc_2_19_x86_64` tag, you need to be compatible with Ubuntu 14.04.

Therefore, a random wheel built on Debian 8 probably does _not_ qualify for the `manylinux_glibc_2_19_x86_64` tag.

A random wheel built on Ubuntu 14.04 _might_ qualify for the tag, but to be certain we’d have to first do some research to check whether there were any distros shipping glibc 2.19 with even older versions of gcc. And of course we’d also need to vendor any necessary libraries, etc.

---

_[View the full topic](https://discuss.python.org/t/the-next-manylinux-specification/1043)._