I'm trying to figure out what the limitation is for the number of
pending nonblocking operations as it does not seem to be specified
anywhere. I apologize if this is better suited to the user list, but
this seemed like information more likely to be available on the dev list.
As part of a toy assig
On Feb 17, 2010, at 3:05 PM, Ralf Wildenhues wrote:
> > The issue is that if the user has to specify -static to their linker,
> > they *also* have to specify --ompi:static, or Bad Things will happen.
> > Or, if they don't specify -static but *only* specify --ompi:static,
> > Bad Things will happen
Looks good to me!
Please commit and file CMRs for v1.4 and v1.5 (assuming this patch applies
cleanly to both branches).
On Feb 16, 2010, at 6:46 AM, Nadia Derbey wrote:
> Hi,
>
> The mpivars.sh genereted in openmpi.spec might in some cases lead to a
> LD_LIBRARY_PATH that contains a trailing
Hello Jeff,
* Jeff Squyres wrote on Wed, Feb 17, 2010 at 08:19:25PM CET:
> The issue is that if the user has to specify -static to their linker,
> they *also* have to specify --ompi:static, or Bad Things will happen.
> Or, if they don't specify -static but *only* specify --ompi:static,
> Bad Thing
Brian and I talked higher bandwidth to figure this out.
The issue is that if the user has to specify -static to their linker, they
*also* have to specify --ompi:static, or Bad Things will happen. Or, if they
don't specify -static but *only* specify --ompi:static, Bad Things will happen.
In sh
On Feb 17, 2010, at 11:23 AM, Jeff Squyres wrote:
> Here's my proposal on how to change the wrapper compilers to understand the
> difference between static and dynamic linking:
>
> *** FIRST: give the wrapper the ability to link one library or all libraries
> - wrapper data text files grow a new
WHAT: Break ABI between 1.4 and 1.5 series.
WHY: To settle the ABI and .so versioning issues once and for all.
WHERE: Open MPI's .so versions and the opal_wrapper compiler.
WHEN: For 1.5[.0]. This is only meaningful if we do it for the *entire* v1.5
series.
TIMEOUT: Next Tuesday teleconf, 23
The problem seems to be that on SL, gfortran defaults to 32-bit binaries while
gcc defaults to 64-bit. If I set FFLAGS=-m64 then configure finishes. Of
course, I have no idea if a Fortran MPI program will actually *work*, but at
least OMPI builds. That's all that matters isn't it? :-).
Greg
On
On Tuesday 16 February 2010, Jeff Squyres wrote:
> We've only got 2 "critical" 1.5.0 bugs left, and I think that those will
> both be closed out pretty soon.
>
> https://svn.open-mpi.org/trac/ompi/report/15
>
> Rainer and I both feel that a RC for 1.5.0 could be pretty soon.
>
> Does anyone hav
I'm checking this issue.
Pasha
Joshua Hursey wrote:
I just noticed that the nightly tarball of v1.4 failed to build in the OpenIB
BTL last night. The error was:
-
btl_openib_component.c: In function 'init_one_device':
btl_openib_component.c:2089: error: 'mca_btl_openib_compone
I just noticed that the nightly tarball of v1.4 failed to build in the OpenIB
BTL last night. The error was:
-
btl_openib_component.c: In function 'init_one_device':
btl_openib_component.c:2089: error: 'mca_btl_openib_component_t' has no member
named 'default_recv_qps'
--
Hello Greg,
* Greg Watson wrote on Tue, Feb 16, 2010 at 07:03:30PM CET:
> When I run configure under Snow Leopard (this is OMPI 1.3.4), I get the
> following:
>
> checking if C and Fortran 77 are link compatible... no
> **
> It
12 matches
Mail list logo