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


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,