Since "disabled by default" is just part of a macro argument we can say
anything we want.
I propose the following:
Index: config/oshmem_configure_options.m4
===
--- config/oshmem_configure_options.m4 (revision 32424)
+++ config/oshme
Paul,
this is a bit trickier ...
on a Linux platform oshmem is built by default,
on a non Linux platform, oshmem is *not* built by default.
so the configure message (disabled by default) is correct on non Linux
platform, and incorrect on Linux platform ...
i do not know what should be done, her
Running "make dist" on trunk I see:
--> Generating assembly for "SPARC" "default-.text-.globl-:--.L-#-1-0-1-0-0"
Could not open ../../../opal/asm/base/SPARC.asm: No such file or directory
Which is apparent because the following lines were never removed
from opal/asm/asm-data.txt
# default compil
I noticed that Open MPI is passing
--with-openmpi-inside=1.7
in the arguments passed to
ompi/contrib/vt/vt/configure
and
ompi/contrib/vt/vt/extlib/otf/configure
The extlib/otf case just tests if the value is set, but the top-level
vt/configure is checking for the specific string "1.7":
My thought was to post initially as a blocker, pending a discussion with Jeff
at tomorrow's telecon. If he thinks this is something we can fix in some
central point (thus catching it everywhere), then it could be quick and worth
doing. However, I'm skeptical as I tried to do that in the most obv
Ralph and Jeff,
I've been digging and find the problem is wider than just the one library
and has manifestations specific to FreeBSD, NetBSD and Solaris. I am
adding new info to the ticket as I unearth it.
Additionally, it appears this existed in 1.8, 1.8.1 and in the 1.7 series
as well.
So, wou
In both trunk and 1.8.2rc3 the behavior is to enable oshmem by default.
In the 1.8.2rc3 tarball the configure help output matches the behavior.
HOWEVER, in the trunk the configure help output still says oshmem is
DISabled by default.
{~/OMPI/ompi-trunk}$ svn info | grep "Revision"
Revision: 32422
Okay, I filed a blocker on this for 1.8.2 and assigned it to Jeff. I took a
crack at fixing it, but came up short :-(
On Aug 3, 2014, at 10:46 PM, Paul Hargrove wrote:
> I've identified the difference between the platform that does link libutil
> and the one that does not.
>
> 1) libutil is
Yeah, I think Howard's commit isn't correct. We shouldn't have to put
opal_config.h after the system includes. I think the real problem is that you
aren't supposed to directly include the system malloc.h as that hoses the
entire memory interceptor stuff.
Howard: can you try reverting your commi
And with following change I can get it to compile again:
diff --git a/opal/mca/mpool/base/mpool_base_frame.c
b/opal/mca/mpool/base/mpool_base_frame.c
index c1b044b..f94b8a5 100644
--- a/opal/mca/mpool/base/mpool_base_frame.c
+++ b/opal/mca/mpool/base/mpool_base_frame.c
@@ -21,12 +21,10 @@
#inclu
I can confirm this on Fedora 20 with gcc 4.8.3.
Running ./configure without any options gives me the same error.
On Mon, Aug 04, 2014 at 04:24:29PM +, Pritchard Jr., Howard wrote:
> Hi Ralph,
>
> Nope that doesn't fix the problem I'm hitting. I tried to build the opmi
> trunk
> on a syste
Hi Ralph,
Nope that doesn't fix the problem I'm hitting. I tried to build the opmi trunk
on a system with a much older gcc compiler (4.4.7) and it compiled :)! But
I'd like to be able to compile opmi with a newer gcc like the one on my opensuse
13.1 box.
The preprocessor is pulling in the syst
I believe the issue is actually in opal/util/malloc.h, Howard. I noticed this
while looking around this weekend - someone included opal_config.h in the
malloc.h file even though it explicitly says "DON'T DO THIS" in that header
file.
#ifndef OPAL_MALLOC_H
#define OPAL_MALLOC_H
#include "opal_
Hi Folks,
As I said last week, I'm noticing now that on my opensuse 13.1 system and gcc
4.8.1, when I do a fresh
checkout of trunk ompi and try to build, without any configure options,
mca_base_mpool_frame.c
does not compile.
The reason is there is a conflict in opal_config_bottom.h and the co
Hi,
Seems like it's impossible to cancel buffered sends with pml/cm.
>From one hand, pml/cm completes the buffered send immediately
>(MCA_PML_CM_HVY_SEND_REQUEST_START):
if(OMPI_SUCCESS == ret &&
\
sendreq->req_send.req_send_mode
It looks like four instances of AC_MSG_CHECKING are missing an
AC_MSG_RESULT or have other configure macros improperly nested between the
two:
checking for epoll support... checking for epoll_ctl... yes
yes
checking for working epoll library interface... yes
yes
checking if user requested CMA bui
I've identified the difference between the platform that does link libutil
and the one that does not.
1) libutil is linked (as an OMPI dependency) only on the working system:
Working system:
$ grep 'checking for .* LIBS' configure.out
checking for OPAL LIBS... -lm -lpciaccess -ldl
checking for OR
Fixed in r32409 : %d and %s were swapped in a MLERROR (printf like)
Gilles
On 2014/08/02 11:07, Gilles Gouaillardet wrote:
> Paul,
>
> about the second point :
> mmap is called with the MAP_FIXED flag, before the fix, the
> required address was not aligned on a page size and hence
> mmap failed.
18 matches
Mail list logo
