FYI - I wasn’t bothered by the default behavior... I was just looking for a
sanctioned way for an installer (e.g. a sysadmin) to make the UCX be loaded
based on LD_LIBRARY_PATH so that there was an ability for the user to swap
in a debug build of UCX at runtime.
On Mon, Feb 1, 2021 at 10:14 AM
On Mon, 1 Feb 2021 14:46:22 +
"Jeff Squyres \(jsquyres\) via devel" wrote:
> On Jan 27, 2021, at 7:19 PM, Gilles Gouaillardet
> wrote:
> >
> > What I meant is the default Linux behavior is to first lookup
> > dependencies in the rpath, and then fallback to LD_LIBRARY_PATH
> > *unless*
On Jan 27, 2021, at 7:19 PM, Gilles Gouaillardet wrote:
>
> What I meant is the default Linux behavior is to first lookup dependencies in
> the rpath, and then fallback to LD_LIBRARY_PATH
> *unless* -Wl,--enable-new-dtags was used at link time.
>
> In the case of Open MPI,
Jeff,
What I meant is the default Linux behavior is to first lookup
dependencies in the rpath, and then fallback to LD_LIBRARY_PATH
*unless* -Wl,--enable-new-dtags was used at link time.
In the case of Open MPI, -Wl,--enable-new-dtags is added to the MPI
wrappers,
but Open MPI is *not*
Thank you for the suggestion of 'configure ...
LDFLAGS="-Wl,--enable-new-dtags"'.
I'm still reading up on its meaning, but wouldn't that change the
behavior across all dependencies that are dynamically linked when I
build Open MPI?
I was specifically wanting *just* these UCX .so files to be
On Jan 27, 2021, at 2:00 AM, Gilles Gouaillardet via devel
mailto:devel@lists.open-mpi.org>> wrote:
Tim,
a simple option is to
configure ... LDFLAGS="-Wl,--enable-new-dtags"
If Open MPI is built with this option, then LD_LIBRARY_PATH takes precedence
over rpath
(the default is the opposite
Tim,
a simple option is to
configure ... LDFLAGS="-Wl,--enable-new-dtags"
If Open MPI is built with this option, then LD_LIBRARY_PATH takes
precedence over rpath
(the default is the opposite as correctly pointed by Yossi in an earlier
message)
Cheers,
Gilles
On 1/27/2021 2:48 AM,
Well, now it is a multi-line patch, and it is more hacky... but this
works for me. Suggestions for a better thing to do to upstream this
functionality would be appreciated.
--- openmpi-4.1.0/config/ompi_check_ucx.m4.orig 2021-01-26
11:13:55.753451526 -0600
+++
Ugh, apparently my one-line patch to
openmpi-4.1.0/config/ompi_check_ucx.m4 wasn't sufficient on a fresh
install... debugging...
On Tue, Jan 26, 2021 at 10:16 AM Tim Mattox wrote:
>
> My environment modules were already setting LD_LIBRARY_PATH to point
> to my UCX lib directory.
>
> The real
My environment modules were already setting LD_LIBRARY_PATH to point
to my UCX lib directory.
The real problem was that OMPI's config/ompi_check_ucx.m4 was
recording the full path to the UCX library if it wasn't found in a
standard system location (e.g. /lib, /lib64, /usr/lib, etc.).
That is
Tim,
Have you tried using LD_LIBRARY_PATH?
I guess "hardcoding the full path" means "link with -rpath", and IIRC,
LD_LIBRARY_PATH
overrides this setting.
If this does not work, here something you can try (disclaimer: I did not)
export LD_LIBRARY_PATH=/same/install/prefix/ucx/1.9.0/lib
I'm specifically wanting my users to be able to load a "debug" vs.
"tuned" UCX module, without me having to make two different Open MPI
installs... the combinatorics get bad after a few versions (I'm
already having multiple versions of Open MPI to handle the differences
in Fortran mpi mod
Hello,
I've run into an application that has its performance dramatically
affected by some configuration options to the underlying UCX library.
Is there a way to configure/build Open MPI so that which UCX library
is used is determined at runtime (e.g. by an environment module),
rather than having
13 matches
Mail list logo
