dolfin @1.6.0_0 +openmpi +suitesparse fails to build

[Schamschula (Marius Schamschula)]

The update to dolfin 1.6.0 (+openmpi +suitesparse variant) fails to build while compiling modulePYTHON_wrap.cxx. main.log attached. I have had two Yosemite machines fail the same way.

[seanfarley (Sean Farley)]

I just installed this and had no problems. Do you have anything installed in /usr/local? The log file suggests some weird things going on with c++ (perhaps stdc++ issues?). I dunno. Maybe boost is throwing in the wrong libs?

[Schamschula (Marius Schamschula)]

Replying to sean@…:

I just installed this and had no problems. Do you have anything installed in /usr/local? The log file suggests some weird things going on with c++ (perhaps stdc++ issues?). I dunno. Maybe boost is throwing in the wrong libs?

Nope. Nothing in /usr/local.

port installed boost gives me boost @1.59.0_1+mpich+no_single+no_static+python27

[seanfarley (Sean Farley)]

Replying to mschamschula@…:

Replying to sean@…:

I just installed this and had no problems. Do you have anything installed in /usr/local? The log file suggests some weird things going on with c++ (perhaps stdc++ issues?). I dunno. Maybe boost is throwing in the wrong libs?

Nope. Nothing in /usr/local.

port installed boost gives me boost @1.59.0_1+mpich+no_single+no_static+python27

This should have been caught by mpi portgroup. You need to match the same mpi variants with boost and its descendants due to the fact that mpi is a compiler wrapper. I'm going to mark this as invalid but if my advice of installing dolfin +mpich doesn't work, feel free to reopen.

[Schamschula (Marius Schamschula)]

Hmm.

When I initially installed dolfin it also installed mpich, as that is the dolfin default variant (+mpich +suitesparse).

So when I attempted to upgrade dolfin to 1.6.0 I ran into this issue. After cleaning out dolfin (and its particular dependencies) I just attempted to install dolfin.

This time I manually set +mpich (redundant, but just make sure). The results (errors) are the same, even though the parallel build job got terminated in a different order.

[seanfarley (Sean Farley)]

Well, damn. There seems to be weird things with libc++ and julia.

[seanfarley (Sean Farley)]

I just dug this up again. I think it's happening because one of your dependency ports was built with gcc. If you can ensure they are all built with clang, then I think that was fix it.

[Schamschula (Marius Schamschula)]

Replying to sean@…:

I just dug this up again. I think it's happening because one of your dependency ports was built with gcc. If you can ensure they are all built with clang, then I think that was fix it.

In other words, use +accelerate, rather than +atlas to build SuiteSparse?

atlas is built using gcc by default.

After all, my only reason to build dolfin was as a prerequisite for octave-fem-fenics.

[seanfarley (Sean Farley)]

Replying to mschamschula@…:

Replying to sean@…:

I just dug this up again. I think it's happening because one of your dependency ports was built with gcc. If you can ensure they are all built with clang, then I think that was fix it.

In other words, use +accelerate, rather than +atlas to build SuiteSparse?

atlas is built using gcc by default.

After all, my only reason to build dolfin was as a prerequisite for octave-fem-fenics.

That *should* be alright but you can try to use clang to build atlas. I was more worried about something using gcc's c++ library as opposed to clang (since they are incompatible). boost smells suspicious but I can't really tell for sure.