On Thu, 20 Jun 2019 15:47:49 -0700 Zhuo Peng <[email protected]> wrote: > > One might argue that everyone releasing manylinux1 packages should use > exactly the same compiler, as provided by the pypa docker image, however > the standard only specifies the maximum versions of corresponding > fundamental libraries [5]. Newer GCC versions could be backported to work > with older libraries [6]. > > A recent change in Arrow [7] has removed most (but not all [8]) of the STL > members in publicly accessible class declarations and will resolve our > immediate problem, but I wonder if there is, or there should be an explicit > policy on the ABI compatibility, especially regarding the usage of template > functions / classes in public interfaces?
IMHO, the only reasonable policy for now is that there is no ABI compatibility. If you'd like to benefit from the PyArrow binary packages, including the C++ API, then you need to use the same toolchain (or an ABI-compatible toolchain, but I'm afraid there's no clear specification of ABI compatibility in g++ / libstdc++ land). > * Our wheel cannot pass “auditwheel repair” > > I don’t think it’s correct to pull libarrow.so and libarrow_python.so into > our wheel and have user’s Python load both our libarrow.so and pyarrow’s, > but that’s what “auditwheel repair” attempts to do. But if we don’t allow > auditwheel to do so, it refuses to stamp on our wheel because it has > “external” dependencies. You know, I wish the scientific communities would stop producing wheels and instead encourage users to switch to conda. The wheel paradigm is conceptually antiquated and is really a nuisance to package developers and maintainers. Regards Antoine.
