From: Roy S. <roy...@ic...> - 2012-11-08 22:09:46
|
On Thu, 8 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: >> if test `uname` = "Darwin" ; then >> CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual" >> else >> CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC" >> fi > > Duh - that would do it. Sorry, I'm on my 5th straight hour of a phone call here. > > Roy, we decided to remove those flags from Darwin since they were > causing unpredictable badness. Mainly I didn't want anyone freaking > out that the automake branch was not doing the right thing. My bad - I'd forgotten about those issues that hit Mac users that forced us to turn off the glibcxx debugging; I'd simply assumed that there was some automake-branch-specific change that had disabled it. --- Roy |
From: John P. <jwp...@gm...> - 2012-11-09 19:00:45
|
In case there's anyone that hasn't muted this conversation yet... I think I've tracked the INL's issue down to mpich2. (I happen to be using mpich2-1.4.1p1, but the problem is probably present in mpich2-1.5 as well.) (Correct me if I'm wrong, but everyone at Texas on a Mac is using OpenMPI, right?) Here's the behavior I'm observing, and a possible explanation: The automake branch works fine for me using hand-built GCC 4.5.4, 4.6.3, and 4.7.2 compilers *without MPI or PETSc* on an otherwise stock Mountain Lion install (no MacPorts). Yes, I really built all those GCCs by hand on a laptop with 4 cores :-P Using the same compilers, if I load my Mpich2 module (which sets CC=mpicc and CXX=mpicxx) the automake branch suddenly exhibits the mysterious segfaults we've discussed here ad-nauseum in the adjoints_ex1 example. So, what the hell, mpich? Let me note first that we use a very vanilla configuration of mpich2, effectively just ./configure --prefix=... --enable-shared --enable-debuginfo make make install What does this produce? $ mpicxx -show g++ -Wl,-flat_namespace \ -I/opt/packages/mpich2/mpich2-1.4.1p1/include \ -L/opt/packages/mpich2/mpich2-1.4.1p1/lib \ -lmpichcxx -lpmpich -lmpich -lopa -lmpl -lpthread Ugh... the prime suspect here has to be -Wl,-flat_namespace. The mpich people must be adding this flag if they detect Darwin... but I think that may be the wrong thing for the Lion and Mountain Lion operating systems. So I could try to figure out how to make mpich not use that flag, but I think my next step is going to be trying out OpenMPI. Anybody have special tips for building that by hand? -- John |
From: John P. <jwp...@gm...> - 2012-11-09 21:07:32
|
Good news, everyone! Automake branch with OpenMPI, PETSc, and GCC-4.7.2 on Mountain Lion seems to finally be working for me (as it has been working for you all for weeks...:-/). Thanks for all the help/suggestions! -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-09 19:12:02
|
On Nov 9, 2012, at 1:00 PM, John Peterson <jwp...@gm...> wrote: > (Correct me if I'm wrong, but everyone at Texas on a Mac is using OpenMPI, right?) Definitely true for me - OpenMPI 1.6.3 here I'd suspect the flat namespace business too - let me know if you have a compelling reason to use mpich, I'm fluent enough now in auto tools I could find a recipe to get it out of there, but it seems a hack. I'd go with OpenMPI if it is feasible. -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-11-09 19:14:00
|
On Fri, Nov 9, 2012 at 1:11 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > I'd go with OpenMPI if it is feasible. > I'd agree with this for the most part, except if you want to do one-sided communication. There are known, ancient, unresolved issues in OpenMPI for one-sided communication functions. Check out some of the PETSc threads were Jed was pointing out some of the issues. Apparently, MPICH2 doesn't suffer from these problems. |