On Oct 11, 2010, at 4:50 PM, Jed Brown wrote: > Note that this is an out-of-source build. > > $ ../configure --enable-debug --enable-mem-debug > --prefix=/home/jed/usr/ompi-1.5-clang CC=clang CXX=clang++ > $ make > [...] > CXXLD vtunify-mpi > vtunify_mpi-vt_unify_mpi.o: In function `VTUnify_MPI_Abort': > /home/jed/src/openmpi-1.5/bclang/ompi/contrib/vt/vt/tools/vtunify/mpi/../../../../../../../../ompi/contrib/vt/vt/tools/vtunify/mpi/vt_unify_mpi.c:63: > undefined reference to `MPI_Abort'
Well this is disappointing. :-\ Can you "make V=1" so that we can see the command line here that is failing? FWIW, this looks like a problem that is self-contained in VampirTrace, so you can likely get a working build with: ./configure --enable-contrib-no-build=vt ... > Leaving out the debugging flags gets me further (no compilation error, just > this link error): > > $ ../configure --prefix=/home/jed/usr/ompi-1.5-clang CC=clang CXX=clang++ > $ make > [...] > CCLD libutil.la > ar: /home/jed/src/openmpi-1.5/bclang/ompi/contrib/vt/vt/util/.libs/libutil.a: > No such file or directory > make[5]: *** [libutil.la] Error 9 That's a weird one -- it should be *creating* that library, so I'm not sure why it would complain that the library doesn't exist...? This could be a red herring, though -- perhaps some oddity in your tree and/or filesystem...? (I've seen this kind of thing before such that a "make distclean" fixed the issue, I think) > I also get this last failure with gcc-4.5.1, but only with the debug flags: > > $ ../configure --enable-debug --enable-mem-debug > --prefix=/home/jed/usr/ompi-1.5-gcc CC=gcc CXX=g++ > $ make > [...] > Making all in util > CC libutil_la-installdirs.lo > CCLD libutil.la > ar: /home/jed/src/openmpi-1.5/bgcc/ompi/contrib/vt/vt/util/.libs/libutil.a: > No such file or directory Same error. Weird. Can you "make V=1" here, too? > There are also lots of these warnings (almost every compilation unit). > > ../../../../../../../../opal/include/opal/sys/atomic_impl.h:124:7: warning: > indirection of non-volatile null pointer will be deleted, not trap > *(int*)(0) = 0; > ^~~~~~~~~~ > ../../../../../../../../opal/include/opal/sys/atomic_impl.h:124:7: note: > consider using __builtin_trap() or qualifying pointer with 'volatile' Well that is annoying, but not a deal breaker -- should be easy to fix. This portion of code is deliberately causing a segv (obviously). We should just call abort() here instead of trying to cause a segv. > Trunk became unbuildable for me a couple months ago, but it was written off > (could find the bug number) as being the fault of my autotools being too new, > thus I haven't built from mercurial recently. Otherwise I might have been > able to point these out prior to the release. Ralph is just going through the pain right now of upgrading to Autoconf 2.68 / Libtool 2.4; hopefully we'll have fixes on the trunk RSN for the newest-of-the-new autotools. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
