Hello, Ashley, did you rebootstrap with Debian's Libtool?
They enable link_all_deplibs=no in their Libtool which changes some things and can cause issues like this. Can't hurt to open a Debian bug report about it (targeted against libtool) so they know this issue exists. Can you try working around it by setting link_all_deplibs to "yes", then rebuilding all the libraries? Like this, done in the top build directory with your current build tree: find . -name libtool | xargs \ sed -i 's/^\(link_all_deplibs=\).*/&no/' find . -name \*.la | xargs ./libtool --mode=clean rm -f make If that does not work, then I'd be very interested in what the failure would look at that point. A more permanent workaround could be in OpenMPI to list each library that is used *directly* by some other library as a dependency. Sigh. Or fix Debian Libtool. Cheers, Ralf * Jeff Squyres wrote on Thu, May 14, 2009 at 07:28:47PM CEST: > Hmm. This may not be pilot error. I build OMPI with a pre-installed > OMPI all the time and they don't conflict during the build (i.e., the > building OMPI always uses the libopen-rte and libopen-pal from the build > tree, not the install tree). Here's my link lines for ompi_info: > > /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -Wall -Wundef > -Wno-long-long -finline-functions -pthread -export-dynamic -o > ompi_info components.o ompi_info.o output.o param.o version.o ../../../ > ompi/libmpi.la -lnsl -lutil -lm > libtool: link: g++ -g -Wall -Wundef -Wno-long-long -finline-functions - > pthread -o .libs/ompi_info components.o ompi_info.o output.o param.o > version.o -Wl,--export-dynamic ../../../ompi/.libs/libmpi.so /users/ > jsquyres/svn/ompi/orte/.libs/libopen-rte.so /users/jsquyres/svn/ompi/ > opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm -pthread -Wl,-rpath - > Wl,/home/jsquyres/bogus/lib > > Notice that libopen-rte.os and libopen-pal.so are explicitly mentioned > by absolute path name. Yours weren't. I wonder why...? > > > On May 14, 2009, at 12:41 PM, Ashley Pittman wrote: > >> >> Libtool is 2.2.6. I use debian unstable so it's normally fairly >> up-to-date, I suppose it's not impossible that a debian update has >> broken things now that I think of it. >> >> I normally build in memfs for speed and have just rebooted my machine >> now, a full rebuild has failed again with the same errors. >> >> All three symbols are shown as B according to nm so they should be >> available. >> >> Actually further testing shows it's user error again, if I remove the >> current install then the build succeeds, it must have been pickings up >> the libopen-pal from the install location rather than from the current >> build. >> >> Ashley Pittman,