Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Build failures on trunk? r21235
From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2009-05-14 13:46:22


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/ -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/ /users/
> jsquyres/svn/ompi/orte/.libs/ /users/jsquyres/svn/ompi/
> opal/.libs/ -ldl -lnsl -lutil -lm -pthread -Wl,-rpath -
> Wl,/home/jsquyres/bogus/lib
> Notice that libopen-rte.os and 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,