Trouble installing with spack

[sampotter]

Trying to use meshpy on a cluster with spack.

After installing spack, I install and load several standard and necessary packages: gcc, python, py-pip, etc. Just the default version of each that is available.

Using spack's version of pip, I install pybind11. Then I clone meshpy from GitHub and try to install it. This seems to work, at least initially. Using, e.g., python setup.py install --user or pip install . leads to the same error. Namely (encountered while trying to import meshpy.triangle as triangle):

In [1]: import meshpy._internals
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-4f0d2eb1fac4> in <module>
----> 1 import meshpy._internals

ImportError: /home/sfp8544/.local/lib/python3.9/site-packages/MeshPy-2020.1-py3.9-linux-x86_64.egg/meshpy/_internals.cpython-39-x86_64-linux-gnu.so: undefined symbol: _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv

Looks like the C++ standard library isn't getting linked. Presumably this is because of some version mismatch along the way. Any thoughts?

[inducer]

Do you happen to have the build log? (Or is there a way for you to recreate it?) I'm curious whether the final link step is done using the C++ compiler. Could you run ldd on /home/sfp8544/.local/lib/python3.9/site-packages/MeshPy-2020.1-py3.9-linux-x86_64.egg/meshpy/_internals.cpython-39-x86_64-linux-gnu.so to see what it says? (Maybe it's getting the wrong version?)

You could probably work around this by running ./configure.py and then adding -lstdc++ (assuming yours is a gcc-based system) to the LDFLAGS variable in siteconf.py and rebuilding. (Make sure to rm -Rf build beforehand.)

[sampotter]

I can dig the build log out if you like, but after tinkering with this some more it seems like it may have something to do with Spack not playing nicely with Python's build system. See this issue.

In my case, I have two other of my own Python libraries with compiled extensions written in Cython calling out to various C++ libraries, and the same sort of weirdness happens. It may be possible to fix it by messing around with runtime_library_dirs in each package's setup.py, but this is pretty tedious and I'm not sure if it's the correct approach. It certainly doesn't scale.

I also just found out that I have access to another cluster with Singularity on it, which should be much smoother sailing. 🤷