Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] "make check" (libtool) failure on Linux/ppc w/ XLC (1.5rc5 and 1.4.3rc1)
From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2010-10-14 14:56:19


Hello Paul,

this bug has been addressed in upstream Libtool commit
v2.2.6-59-gb7dbec6:
<http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=v2.2.6-59-gb7dbec6>

It is not wholly fixed yet, but for all cases interesting to OpenMPI.
(A libtoolized package using only Fortran but no C compiler may still
have issues.)

Cheers,
Ralf

* Paul H. Hargrove wrote on Sat, Aug 28, 2010 at 02:39:27AM CEST:
> I reran the build as Ralf requested (setting
> shlibpath_overrides_runpath=yes in the libtool script).
> The build and check were SUCCESSful!
>
> I have provided Ralf with the requested files off-list.
> -Paul
>
>
> Ralf Wildenhues wrote:
> >* Paul H. Hargrove wrote on Fri, Aug 27, 2010 at 03:54:54AM CEST:
> >>>I am now looking at using IBM's XLC compilers for ILP32 builds on
> >>>the same Linux/PPC64 platform for which I've reported some
> >>>XLC/LP64 bugs.
> >>>
> >>>What I find now is that "make check" is failing with the loader
> >>>unable to find libmpi.so.0.
> >>>This is with both 1.5rc5 and 1.4.3rc1.
> >>>This occurs with xlc, but things are just fine with gcc.
> >
> >>>As I said above, the problem is NOT occuring w/ gcc. So, I've
> >>>attached the "./libtool --config" output for the xlc and gcc
> >>>builds, which I see differ in more ways than I would have
> >>>expected.
> >
> >The thing that's unexpected to me is the shlibpath_overrides_runpath
> >difference.
> >
> >>While I still don't know the root cause, the following diff between
> >>the libtool-generated wrappers for a gcc and xlc build make the
> >>cause of the "make check" failure fairly obvious:
> >
> >Please set shlibpath_overrides_runpath=yes in the libtool script for
> >xlc, then try 'make clean all check'. Please send config.log for xlc
> >(packed).
> >
> >Thanks,
> >Ralf