Side note: it's not only STL containers, it's also any non-trivial stdlib type that appears in headers. Such as std::shared_ptr<>.
So I'm not sure the endeavour makes sense at all. You'll have to try and follow the libstdc++ ABI spec: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html Regards Antoine. On Fri, 21 Jun 2019 18:12:02 +0200 Antoine Pitrou <[email protected]> wrote: > 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. > > >
