Unfortunately, we don't have any control over the toolchain and toolchain version or the compilation/linking flags that pycapnp uses, since it's a 3rd-party project for us. We also don't have any control over which version of capnproto a given version pf pycapnp would use or which patches it might apply to it, if needed. pycapnp evolves completely independently from our software. Furthermore, pycapnp is built automatically upon installation from PyPi, using whatever version/type compiler that the user happens to have. E.g., pip install pycapnp==0.5.8 automatically downloads and builds pycapnp, including the build of some version of capnproto module that's specific to that version of pycapnp.
Our own software is the nupic.bindings package distributed as binary wheels for windows, osx, and linux. The linux wheel in particular is a "manylinux" wheel per PEP-513, which is built by definition on an old CentOS system using an old toolchain. As you can see, there is absolutely no way to guarantee ABI compatibility between the compiled version of capnproto in pycapnp and the one used by the python extensions in nupic.bindings. It's well known that C++ is not a robust interface, since - unlike C - it does not have a stable ABI. There is variability introduced by version of ABI supported by a given toolchain as well as the type of toolchain (e.g., clang vs. g++). Compatibility is also affected by build flags. Finally, the version of capnproto sources in pycapnp is outside our control and could easily differ from the version of capnproto compiled/linked into the nupic.bindings extension. -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
