Would building our manylinux2010 wheels against https://github.com/pypa/manylinux/pull/252 solve the C++11 problems? In that case we should just do that. Otherwise let's propose a minimally modified manylinux2011 that fixes C++11 support so we can move on and don't have to wait 9 more months till manylinux2014 or whatever will support c++14.
On Wed, Feb 6, 2019 at 9:14 AM Philipp Moritz <pcmor...@gmail.com> wrote: > The problems arose if some functionality of C++11 <future> were used. It > led to certain symbols being statically linked into the shared library > which clashed with other shared libraries that had the same symbols in the > same address space, linked against a different version of libstdc++ > (specifically, tensorflow's). There is some discussion about this in > https://github.com/apache/arrow/pull/3177. > > This might happen in the future again if pre g++ 5 stdlib is mixed with > post g++ 5. But with manylinux20xx we will be in a better situation if the > major packages (TensorFlow, PyTorch, Ray, Arrow) standardize on g++ >= 5. > Older manylinux1 packages from pip might still clash but we can flag them > as not manylinux20xx compatible and work towards them being fixed. > > On Wed, Feb 6, 2019 at 5:37 AM Antoine Pitrou <anto...@python.org> wrote: > >> >> Le 06/02/2019 à 14:27, Manuel Klimek a écrit : >> > On Wed, Feb 6, 2019 at 12:38 PM Antoine Pitrou <anto...@python.org >> > <mailto:anto...@python.org>> wrote: >> > >> > >> > Le 06/02/2019 à 01:06, Philipp Moritz a écrit : >> > > Thanks for the meeting! One question concerning a point that is >> still >> > > not super clear to me: >> > > >> > > Say we define a new manylinux standard based on gcc >=5 (with >> stable >> > > c++11 support). There will still be a lot of wheels form the >> > manylinux1 >> > > days that are built against gcc 4.8 that might use the c++11 >> features >> > > before they became stable. How do we prevent bugs from that? Is >> > the plan >> > > to convince everybody who uses these c++11 features to use the new >> > > manylinux standard? >> > >> > Yes, that's a bit of a problem. >> > >> > This discussion arised from the incompatibility between Tensorflow >> > wheels (compiled with a later toolchain) and other Python wheels >> > (compiled with a manylinux1-compatible toolchain). >> > >> > >> > Do you know where these communicate with std types? (due to ABI tagging >> > loading them into the same process should work, right?) >> >> They don't. I don't remember the specifics, Philipp Moritz might know >> more about this. >> >> Regards >> >> Antoine. >> >
