Ralph,
In file included from
../../../../../trunk/opal/mca/event/libevent207/libevent207_module.c:44:
../../../../../trunk/opal/mca/event/libevent207/libevent/event.h:165:33: error:
event2/event-config.h: No such file or directory
Looks like you forgot some files.
Aurelien
Le 25 oct. 201
It's a VPATH build issue -- I have a fix that I am testing right now before I
commit... (am testing with "make distcheck" which takes at least 30 mins...)
On Oct 25, 2010, at 1:53 PM, Aurélien Bouteiller wrote:
> Ralph,
>
> In file included from
> ../../../../../trunk/opal/mca/event/libevent
I was literally just about to commit that (i.e., when I ran "svn up" before
committing 23937 and 23938, it merged your change exactly on top of mine). :-)
With the changes from 936, 937, and 938, I am able to "make distcheck"
successfully (and therefore also VPATH build properly).
On Oct 25,
So now we're in good shape, at least for compiling. IB and TCP seem to work,
but SM deadlock.
george.
On Oct 25, 2010, at 14:33 , Jeff Squyres wrote:
> I was literally just about to commit that (i.e., when I ran "svn up" before
> committing 23937 and 23938, it merged your change exactly on t
On Oct 25, 2010, at 3:21 PM, George Bosilca wrote:
> So now we're in good shape, at least for compiling. IB and TCP seem to work,
> but SM deadlock.
Ugh.
Are you debugging this, or are we? (i.e., me/Ralph)
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.ci
I dug into this a bit.
The problem is in the SM BTL init where it's waiting for all of the peers to
set seg_inited in shared memory (so that it knows everyone has hit that point).
We loop on calling opal_progress while waiting.
The problem is that opal_progress() is not returning (!).
It ap
On Oct 25, 2010, at 20:22 , Jeff Squyres wrote:
> I dug into this a bit.
>
> The problem is in the SM BTL init where it's waiting for all of the peers to
> set seg_inited in shared memory (so that it knows everyone has hit that
> point). We loop on calling opal_progress while waiting.
>
>
Hmmmcomparing the "new" code with the "old" one, I see some thread locking
in the "old" code that didn't make it across. Is it possible this could be
affecting shared memory?
There were other hand edits in the event code - hard to tell sometimes what was
put in by us vs already there, and w
