As we saw it, it was 6 of one and a half-dozen of the other.
Specifically:
- Almost everything is going to require libopal. Let's swag and say
90% of components will need libopal.
- All ORTE components will need liborte. Maybe half of OMPI components
need it (WAG).
So really, all we're ta
Hi George,
* George Bosilca wrote on Fri, Sep 23, 2005 at 06:05:28PM CEST:
>
> But I still see a problem. **Just to refresh the memories, I'm the only
> complaining on a regular base about the useless dependencies**. And
> there are a lot. I know that most of the shared libraries in ompi use
>
I'm not sure I understand -- all frameworks have priorities for their
components...?
On Sep 23, 2005, at 11:55 AM, George Bosilca wrote:
This will benefit to several components: BTL/PTL, PML, having a common
set of functions will be really useful. I just have a request. If we
specify something
Guys,
I'm looking into some ideas coming during the Euro PVM/MPI meeting. I
need as many as possible of the includes files for different MPI
implementations. If you have access to any MPI implementation (not the
one freely available for download), please send me their mpi.h and
mpif.h files.
That was the problem that trigger my question. If we remove the
dependence to the libopal in the malloc_interpose we can compile the
module. Otherwise the compilation fails because the generation of the
mca_memory_malloc_interpose happens priori to the libopal.so. However,
reading the last emai
This will benefit to several components: BTL/PTL, PML, having a common
set of functions will be really useful. I just have a request. If we
specify something like "--mca btl self,mvapi" I think it can be useful
to get them in the specified order. For some components (like the BTL)
it doesn't ma
On Sep 21, 2005, at 3:37 PM, David R. (Chip) Kent IV wrote:
I managed to find a number of problems with the mpif.h when I tried it
on
a big application. It looks like a lot of key constants are not
defined
in this file. So far, MPI_SEEK_SET, MPI_MODE_CREATE, MPI_MODE_WRONLY
have broken the b
Tim --
Doesn't this violate the "nothing should call MPI functions" rule?
I also ask because there's a bunch of places where we alloc temporary
buffers in the collectives -- should we be using whatever the back-end
to MPI_Alloc_mem is instead of malloc()?
(this would apply to both the basic
Fixed.
Sorry -- didn't know that this was still a problem.
On Sep 21, 2005, at 4:47 PM, Tim S. Woodall wrote:
Note that the recent change to the configure script(s) to use
--with-mvapi
instead of --with-btl-mvapi are not complete. I've recently had to use
both
to compile mvapi. This is cau
On Sep 23, 2005, at 6:18 AM, Ralf Wildenhues wrote:
I think I found a small error in the patch, see proposed fix below.
Yep, this showed up in the nightlies as well.
The issue here is that this component is *always* built statically, and
is therefore part of libopal itself (and therefore can
Short version:
--
I'd like to have a single, top-level MCA param for each framework that
controls the "include" and "exclude" behavior of components. Something
like:
mpirun --mca btl self,mvapi ...
would "include" self, mvapi (this actually already works for dynamic
com
Andrew,
* Ralf Wildenhues wrote on Fri, Sep 23, 2005 at 10:42:34AM CEST:
> * Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST:
> > On Sep 22, 2005, at 12:56 PM, George Bosilca wrote:
> > >
> > > Now we get this message for all .so file we generate:
> > > libtool: install: warning:
Hi George, Andrew,
* Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST:
> I'm going to take a stab at this, though Jeff should be the definitive
> authority on how this all works.
Yes. FWIW, I believe you summarized it quite well.
> On Sep 22, 2005, at 12:56 PM, George Bosilca wrot
13 matches
Mail list logo
