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,

Reply via email to