Add py-meep package and dependencies#1156
Conversation
adamjstewart
force-pushed
the
features/py-meep
branch
from
c3f36b7 to
d5313d1
Compare
| collecting replacement for C malloc or C++ new.""" | ||
|
|
||
| homepage = "http://www.hboehm.info/gc/" | ||
| url = "http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz" |
There was a problem hiding this comment.
So Spack auto-detected the package name for this one as gc, but I manually changed it to bdw-gc for three reasons:
- The GitHub repo is named bdwgc
- The Homebrew package is named bdw-gc
- There may be other garbage collectors added to Spack someday?
Let me know if you have any strong opinions on this. I really don't care either way.
|
So I was getting a mysterious seg fault/core dump whenever I tried building guile and had no idea why. I contacted the developers but they couldn't figure it out either. I tried removing dependencies one at a time and building with the system libraries and eventually discovered that the problem was libiconv. Guile, gettext, and libunistring all depend on libiconv. But if even one of them was built with Spack's libiconv, guile would seg fault. Note that libiconv passed all of it's tests, so I don't think there's anything wrong with the package itself. From the libunistring
Based on this, I think it's pretty safe to assume that libiconv isn't important. |
|
Last remaining hurdle. I think I have everything installed and passing all of it's tests. The only problem is that when I try to import py-meep, I get this error: I have no idea what this means. Please save me. |
adamjstewart
force-pushed
the
features/py-meep
branch
from
9e51858 to
12ca121
Compare
adamjstewart
force-pushed
the
features/py-meep
branch
from
12ca121 to
1b10ddd
Compare
adamjstewart
force-pushed
the
features/py-meep
branch
from
e5cb547 to
6340fdb
Compare
adamjstewart
changed the title
|
I solved the aforementioned problem. I just needed to build meep and its dependencies with |
|
|
||
| if '+mpi' in spec: | ||
| include_dirs.append(spec['mpi'].prefix.include) | ||
| library_dirs.append(spec['mpi'].prefix.lib) |
There was a problem hiding this comment.
I don't think this actually works. The package is linked to MPI properly:
$ ldd py-meep-1.4.2-ikjdpnikleqeaxvncnag37bhhdnfafoj/lib/python2.7/site-packages/_meep_mpi.so
...
libmpi.so.20 => /blues/gpfs/home/software/spack-0.9.1/opt/spack/linux-centos6-x86_64/gcc-6.1.0/openmpi-2.0.0-tapt7aozvnpq4m7tf7cbsa5zefy4kc6s/lib/libmpi.so.20 (0x00002b0cbd86b000)
...
but when I import it:
$ python
Python 2.7.12 (default, Jul 21 2016, 15:23:03)
[GCC 6.1.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import meep_mpi
Neither libmpi.so.0 nor libmpi.so found. Fatal error.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/soft/spack-0.9.1/opt/spack/linux-centos6-x86_64/gcc-6.1.0/python-2.7.12-hfkksvc2jgtlvkjagr33k6khrnj7yfqt/lib/python2.7/site-packages/meep_mpi.py", line 5088, in <module>
raise e
OSError: libmpi.so: cannot open shared object file: No such file or directory
it can't find MPI.
There was a problem hiding this comment.
By the way, if I add MPI to my LD_LIBRARY_PATH, py-meep finds it, so I don't think this problem should hold up the PR.
adamjstewart
force-pushed
the
features/py-meep
branch
from
e6c65dc to
ab885a5
Compare
|
ping @tgamblin |
* Adds support for Caliper variant and enables it by default. * Updates Caliper recipe from upstream and fixes an issue in CoreNEURON.
3 participants
Still a work in progress. I couldn't get
gettextto build at first, so I'm trying to overhaul that. I'm adding a lot of packages for system libraries in the hope that we no longer need to runsudo yumandsudo apt-getto actually install things. Let me know if any of the extra dependencies give anybody a heart attack.