Jim Langston wrote:
Hi Rolf,
Thanks for the pointers, they are very clear and concise. I followed
the general
flow of what was done to fix the issue in 1.3 and did something
similar for 1.2.9.
In mpicxx.cc, I did this change:
#include
#ifdef LOCK_SHARED
static const int ompi_synch_lock_s
Hi Rolf,
Thanks for the pointers, they are very clear and concise. I followed the
general
flow of what was done to fix the issue in 1.3 and did something similar
for 1.2.9.
In mpicxx.cc, I did this change:
#include
#ifdef LOCK_SHARED
static const int ompi_synch_lock_shared = LOCK_SHARED ;
The file is present on the 2.6.19 distribution, which is the most
current I have access to.
However, after looking at the code, I realized that we no longer need
that include file anyway - so I have removed it. Hopefully, that
should let you build.
Ralph
On Jan 5, 2009, at 12:08 PM, Jeff
Is there some other file that should be included instead?
On Jan 5, 2009, at 1:16 PM, Thomas Ropars wrote:
Hi,
I don't manage to compile the code from the svn r20196.
I get the following error:
pstat_linux_module.c:34:73: error: asm/page.h: No such file or
directory
make[2]: *** [pstat_li
Addendum to the previous message concerning this discussion: I think
we should stick with including opal_stdint everywhere instead of
inttypes.h (this file does not always exist on ansi pedantic compilers).
Aurelien
Le 4 janv. 09 à 00:09, timat...@osl.iu.edu a écrit :
Author: timattox
Dat
Tim,
To answer to your question in ticket #869: the only known missing
feature to the opal_stdint.h is that there is no portable way to
printf size_t. Their type is subject to so many changes depending on
the platform and compiler that it is impossible to be sure that
PRI_size_t is not go
Hi,
I don't manage to compile the code from the svn r20196.
I get the following error:
pstat_linux_module.c:34:73: error: asm/page.h: No such file or directory
make[2]: *** [pstat_linux_module.lo] Error 1
It seems that it is because new Linux kernels no longer install
asm/page.h (I use a 2.6.2
On Jan 5, 2009, at 10:09 AM, Brian W. Barrett wrote:
I think this sounds reasonable, if (and only if) MPI_Accumulate is
properly handled. The interface for calling the op functions was
broken in some fairly obvious way for accumulate when I was writing
the one-sided code. I think I had to
I think this sounds reasonable, if (and only if) MPI_Accumulate is
properly handled. The interface for calling the op functions was broken
in some fairly obvious way for accumulate when I was writing the one-sided
code. I think I had to call some supposedly internal bits of the
interface to m
WHAT: Converting the back-end of MPI_Op's to use components instead of
hard-coded C functions.
WHY: To support specialized hardware (such as GPUs).
WHERE: Changes most of the MPI_Op code, adds a new ompi/mca/op
framework.
WHEN: Work has started in an hg branch (http://www.open-mpi.org/hg/h
Hi Jim:
Yes, we ran into this also and your diagnosis is correct. The details
are in this ticket.
https://svn.open-mpi.org/trac/ompi/ticket/1477
We fixed it in the trunk and in the 1.3 series but we never backported
it to the 1.2 series
as 1.3 was going to be released "really soon". Here is
11 matches
Mail list logo
