…Yeah, I read all that and I’m still baffled at how a definition of std::call_once in one ELF namespace is affecting another namespace entirely. In any case, it sounds like this is effectively some kind of toolchain bug, and not something that we can solve with compatibility tags, so we should probably move the discussion eleswhere.
Right, the idea is that manylinux_glibc_2_12_x86_64 doesn’t mean “this was built on some system that happened to have glibc 2.12”, it means “we believe that if you have a system with glibc 2.12 on x86-64, then this wheel will work”. It’s a claim about compatibility, not a record of the build environment.
That’s a fair point. Up above @ncoghlan suggested having a range of broadly-compatible-linux-environments named like manylinux_${compatibility rule}_${some kind of version info}. Another approach would be to decide that manylinux is the name for “broadly compatible with mainstream glibc-based distros” (that’s pretty much what it means now!), and use other tags for other compatibility heuristics. So e.g. you might have:
manylinux_12_x86_64(= installs on systems with glibc 2.12+)vfxlinux_cy2019_x86_64(= installs on systems that are believed to implement the VFX Reference Platform Calendar Year 2019 compatibility profile)alpinelinux_somekindofversioninfo_x86_64(… you get the idea)
It’s basically a question of taste, but since we’ve had a few rounds of confusion over the string manylinux_glibc then maybe it’s better to avoid it.