Le 30/01/2019 à 14:30, Manuel Klimek a écrit : > > > > What would the requirements for such a toolchain wheel be for it > to have a chance to be widely used? (note that I come from a C++ > background and don't have a lot of experience with Python outside of > modules using C++ under the hood :) > > In principle I would think that the requirement would be that we > demonstrate that wheels built with the newer compiler toolchain and > libstdc++ dependency can coexist with manylinux1 / manylinux2010 > packages. This is supposed to be the promise of devtoolset-produced > libraries anyhow. A potential problem might be projects that need to > pass std::* objects between shared libraries in their C++ API. For > example, the "turbodbc" package uses the "pyarrow" package's C++ API. > This would just mean that any wheel that needs to depend on a wheel in > the "TF/PyTorch-compatible toolchain" ecosystem would necessarily need > to use the alternative build toolchain instead of manylinux* > > Fundamentally, the C++ dependency chain seems to be solvable with pip > package deps down to the libstdc++/libc++ level. > I think we'd basically need to provide: > a) a toolchain pip package to depend on > b) a manylinux docker image with those libraries and a compiler > toolchain targeting them installed so packagers have an easy way to > build these packages
Am I reading you wrong, or are you actually proposing to package another libstdc++ version as a Python wheel? If so, are you going to claim that the given wheel is manylinux-compatible? Regards Antoine.
