On Thu, Oct 14, 2010 at 22:36, Jeff Squyres <jsquy...@cisco.com> wrote:
> 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? > libtool: link: clang++ -DVT_MPI -g -finline-functions -pthread -o .libs/vtunify-mpi vtunify_mpi-vt_unify_mpi.o vtunify_mpi-vt_unify.o vtunify_mpi-vt_unify_defs.o vtunify_mpi-vt_unify_defs_hdlr.o vtunify_mpi-vt_unify_events.o vtunify_mpi-vt_unify_events_hdlr.o vtunify_mpi-vt_unify_markers.o vtunify_mpi-vt_unify_markers_hdlr.o vtunify_mpi-vt_unify_stats.o vtunify_mpi-vt_unify_stats_hdlr.o vtunify_mpi-vt_unify_tkfac.o ../../../util/.libs/libutil.a ../../../extlib/otf/otflib/.libs/libotf.so -lz -L/home/jed/src/openmpi-1.5/bclang/ompi/contrib/vt/vt/../../../.libs /home/jed/src/openmpi-1.5/bclang/ompi/contrib/vt/vt/../../../.libs/libmpi.so -ldl -lnsl -lutil -lm -pthread -Wl,-rpath -Wl,/home/jed/usr/ompi-1.5-clang/lib 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' > 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) > Sure enough, using a new build directory, I get the same error as above: libtool: link: clang++ -DVT_MPI -O3 -DNDEBUG -finline-functions -pthread -o .libs/vtunify-mpi vtunify_mpi-vt_unify_mpi.o vtunify_mpi-vt_unify.o vtunif y_mpi-vt_unify_defs.o vtunify_mpi-vt_unify_defs_hdlr.o vtunify_mpi-vt_unify_events.o vtunify_mpi-vt_unify_events_hdlr.o vtunify_mpi-vt_unify_markers.o vtunify_mpi-vt_unify_markers_hdlr.o vtunify_mpi-vt_unify_stats.o vtunify_mpi-vt_unify_stats_hdlr.o vtunify_mpi-vt_unify_tkfac.o ../../../util/.libs/ libutil.a ../../../extlib/otf/otflib/.libs/libotf.so -lz -L/home/jed/src/openmpi-1.5/bclang-nodbg/ompi/contrib/vt/vt/../../../.libs /home/jed/src/open mpi-1.5/bclang-nodbg/ompi/contrib/vt/vt/../../../.libs/libmpi.so -ldl -lnsl -lutil -lm -pthread -Wl,-rpath -Wl,/home/jed/usr/ompi-1.5-clang-nodbg/lib vtunify_mpi-vt_unify_mpi.o: In function `VTUnify_MPI_Abort': ../../../../../../../../ompi/contrib/vt/vt/tools/vtunify/mpi/vt_unify_mpi.c:(.text+0xa): undefined reference to `MPI_Abort' Grab config.log for this case here: http://59A2.org/files/openmpi-1.5-clang-config.log > > 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? This one completes with a clean build directory, reconfiguring from a non-debug build must have caused this issue the first time around. Jed