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 (
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
- "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
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
* 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,