Clarify docs around manylinux and c++

docs/cpp_standards.md

@@ -5,10 +5,27 @@ title: Modern C++ standards
 Building Python wheels with modern C++ standards (C++11 and later) requires a few tricks.
 
 
-## manylinux1 and C++14
-The default `manylinux1` image (based on CentOS 5) contains a version of GCC and libstdc++ that only supports C++11 and earlier standards. There are however ways to compile wheels with the C++14 standard (and later): https://github.com/pypa/manylinux/issues/118
+## manylinux and C++
+Be aware that the `manylinux*` standards constrain _symbol versions_ in `libstdc++.so`. If you want to link `libstdc++.so` dynamically, then your desired `manylinux*` standard will constrain your gcc version, and thus your C++ standard.
 
-`manylinux2010` and `manylinux2014` are newer and support all C++ standards (up to C++17).
+Cross-referencing [current manylinux standards](https://github.com/mayeut/pep600_compliance/blob/f86a7d7c153cc45aa3f2add6ffcf610c80501657/pep600_compliance/tools/policy.json) with [gcc's symbol versions](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html) and [libstdc++'s language support](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html), we have:
+ * `manylinux1`: gcc 4.1.1
+ * `manylinux2010`: gcc 4.4.2
+ * `manylinux2014`: gcc 4.8.3
+ * `manylinux_2_24`: gcc 6.1.0 (stable C++14 ABI)
+ * `manylinux_2_27`: gcc 7.2.0 (stable C++14 ABI)
+
+The first release of a complete and stable C++17 ABI is gcc 9.1. There is currently no official `manylinux*` standard that supports this version.
+
+gcc's support for c++11 isn't as well-tracked in their documentation. Other gcc versions may have incomplete or unstable-ABI support for C++ standards not mentioned here. You will have to test for yourself.
+
+The pypa-maintained `manylinux1`, `manylinux2010` and `manylinux2014` docker images contain *recent* versions of gcc. These do not map precisely to the version requirements implied by the `manylinux*` standards, and **if you compile C++ code with these images, your wheel may not be compatible with that `manylinux*` standard**. `auditwheel repair` will not vendor `libstdc++.so`, so it can't do anything if your symbols are too new for the desired standard.
+
+**If you want to support an older `manylinux*` with a newer C++ standard, you may need to use `LDFLAGS=-static-libstdc++`**. This avoids version conflicts, at the expense of larger code size, and possibly subtle side effects. This also means you could use an older gcc with experimental support for your desired C++ standard, as there won't be any symbol conflicts when running on a newer system.
+
+If you really want dynamic linking with a newer C++ standard, you could just declare the non-specific `linux` platform tag, instead of a `manylinux*` tag. Use `AUDITWHEEL_PLAT=linux`.
+
+For more information, see https://github.com/pypa/manylinux/issues/118
 
 ## macOS and deployment target versions