Subject: Re: [MTT users] LD_LIBRARY_PATH setting in Run.pm masks a wrapper compiler issue
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-05-05 16:10:01
On May 5, 2008, at 2:47 PM, Ethan Mallove wrote:
> Line 386 of MTT/Test/Run.pm sets LD_LIBRARY_PATH. This
> appears to have masked a problem in my wrapper compiler
> (missing -R/foo/lib flags).
>
> if ($mpi_install->{libdir}) {
> if (exists($ENV{LD_LIBRARY_PATH})) {
> $ENV{LD_LIBRARY_PATH} = "$mpi_install->{libdir}:" .
> $ENV{LD_LIBRARY_PATH};
> } else {
> $ENV{LD_LIBRARY_PATH} = $mpi_install->{libdir};
> }
> }
>
> Is the rationale for setting LD_LIBRARY_PATH for the
> mpirun's the same as the rationale described below (from
> GNU_Install.pm)?
No, it's set that way for other MPI's that may need to find
their .so's, but weren't linked with -R.
> If so, could we make MTT a little smarter. E.g., actually
> check for a libmpi.so (and/or other possibly conflicting
> DSOs), and if there's no conflict then skip the
> LD_LIBRARY_PATH setting. (This way a wrapper compiler issue
> is not masked.)
I'd prefer an INI param to check whether you want to disable this
behavior. That is, the default should be enabled, but you can turn it
off if you want to.
The reason is that some MPI's don't have a libmpi.so -- it may be
named something else (e.g., libmpich.so).
-- Jeff Squyres Cisco Systems