Hi folks
I was reviewing the trunk MTT results tonight and found a ton of
failures in the Intel test suite on IU's odin cluster. That cluster -
usually- runs pretty clean, so I took a closer look.
What I found was that the errors were all typified by the following:
MPITEST_INFO ( 0
Josh - this is almost certainly what happened. Yoibks. Unfortunately, there's
good reasons for it. :(
What about if we proxy calls to lt_dlopen through an opal function call?
-jms
Sent from my PDA. No type good.
- Original Message -
From: devel-boun...@open-mpi.org
To: Open MPI Develo
- "Ralf Wildenhues" wrote:
> You can probably solve most of these issues by just
> versioning the directory names where you put the files;
To be honest I'm not sure if this is something that
OMPI should be looking to solve, we have lots of
different versions installed on our clusters just
u
It was mentioned to me that r21731 might have caused this problem by
restricting the visibility of the libltdl library.
https://svn.open-mpi.org/trac/ompi/changeset/21731
Brian,
Do you have any thoughts on how we might extend the visibility so that
MCA components could also use the libtool
If I follow correctly, the problem is not with the Self CRS component
USING lt_dl*(), but rather a failure is occurring when one is trying to
dynamically load the component itself. If that is correct, then I'd
guess that some automake/libtool magic incantation is missing. It may
be as simple
Once upon a time, the Self CRS module worked correctly, but I admit
that I have not tested it in a long time.
The Self CRS component uses dl_open and friends to inspect the running
process for a particular set of functions. When I try to run an MPI
program that contains these signatures I g
* Jeff Squyres wrote on Sat, Jul 25, 2009 at 07:59:25PM CEST:
> On Jul 25, 2009, at 12:59 PM, Iain Bason wrote:
> >> We have talked many times about doing proper versioning for
> >> OMPI's .so libraries (e.g., libmpi.so -- *not* our component DSOs).
> >
> >Forgive me if this has been hashed out, bu
