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
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
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.
* 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 -
> 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
>> 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
>> Ashley Pittman,