As part of the manylinux wheel effort, I have taken several steps to alleviate this issue in nupic.bindings build:
- Hide all symbols in the nupic.bindings extension DSOs (except the python extension initialization function, of course) on *nix builds. This prevents unintended preemption of nupic.bindings symbols by other extensions and vise versa.
- Exclude capnproto sources from nupic.bindings extensions build and forcing preload of pycapnp, thus forcing a single capnproto build to be used. This solves the “hang” problem that both this thread’s author and I ran into. That problem resulted from an object created by pycapnp’s capnroto code (compiled on Ubuntu 16.04 with newer c++ ABI) being manipulated by nupic.bindings’ capnproto code (compiled on a system with an older, incompatible c++ ABI). It’s easy to see how this would lead to problems.
- Link nupic.bindings extension DSOs with static libstc++. In combination with the first item above, this ensures that nupic.bindings extensions can catch exceptions whose c++ ABI changed in newer toolchains (e.g, std::ios_base::failure). See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 .
NOTE Step number 2 above is only a short-term solution as it relies on “promiscuous” behavior by a 3rd party python extension (pycapnp) that exposes all its symbols against python extension best practices. We will of course need to find a more robust solution for the long-term.
Hope this helps someone.