I agree that wheels are a nuisance for package maintainers and Google would be doing everyone a favor if they would either stop using them or conform to the standard (or an evolved version thereof).
On Fri, Jun 21, 2019 at 11:35 AM Antoine Pitrou <[email protected]> wrote: > > > 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. > > > > > > > > >
