Re: [OMPI devel] orte does not compile on XT5 (pgcc)

Did this ever get fixed? Anyone able to do so (I can't - no access to PGI or environment)? On Sep 29, 2010, at 1:45 PM, Aurélien Bouteiller wrote: > Here is the problem. The PGI compiler is especially paranoid regarding post > declared structures typedefs. It looks like the include ordering

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

On Oct 25, 2010, at 9:29 PM, George Bosilca wrote: > 1. Not all processes deadlock in btl_sm_add_procs. The process that setup the > shared memory area, is going forward, and block later in a barrier. Yes, I'm seeing the same thing (I didn't include all details like this in my post, sorry). I

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

Btw it strikes me that we could put the old libevent back as a separate component for comparisons. Sent from my PDA. No type good. On Oct 26, 2010, at 6:20 AM, "Jeff Squyres" wrote: > On Oct 25, 2010, at 9:29 PM, George Bosilca wrote: > >> 1. Not all processes deadlock

Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib

Hi all, This problem may be a detail, but it bugs me a lot, so I'd like to have it fixed. Here is a patch that changes the path setting algorithm to "last component wins" instead of "first component wins". This is as wrong as was the original code, except that it is consistent with the way

Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib

On Oct 26, 2010, at 6:55 AM, Sylvain Jeaugey wrote: > This problem may be a detail, but it bugs me a lot, so I'd like to have it > fixed. Fair enough. :-) > Here is a patch that changes the path setting algorithm to "last component > wins" instead of "first component wins". > > This is as

Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib

On Tue, 26 Oct 2010, Jeff Squyres wrote: I don't think this is the right way to fix it. Sorry! :-( I don't think it is the right way to do it either :-) I say this because it worked somewhat by luck before, and now it's broken. If we put in another "it'll work because of a side effect of

Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib

I'll take a look at fixing this the right way today. Since I wrote both the original autogen.sh that guaranteed static-components was ordered and PREFIX code, I had considered it to be a documented feature that there was strong otdering in the static-components list. So personally, I'd

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

I like the idea of putting the old libevent back as a separate component, just for performance/correctness comparisons. I think it would be good for the trunk, but for the release branches just choose one version to ship (so we don't confuse users). -- Josh On Oct 26, 2010, at 6:27 AM, Jeff

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

There are fundamental differences between the two event engines. Just as an example the new one allow us to have multiple pools of sockets, making a lot easier to implement optimized asynchronous operations using multiple threads. If we add the old engine back, we will either have to implement

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

On Oct 26, 2010, at 11:21 AM, George Bosilca wrote: > There are fundamental differences between the two event engines. Just as an > example the new one allow us to have multiple pools of sockets, making a lot > easier to implement optimized asynchronous operations using multiple threads. > If

[OMPI devel] 1.5.x plans

On the teleconf today, two important topics were discussed about the 1.5.x series: - 1. I outlined my plan for a "small" 1.5.1 release. It is intended to fix a small number of compilation and portability issues. Everyone seemed to think that this was an ok idea. I have done some

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23936

On Oct 26, 2010, at 1:27 PM, Ralph Castain wrote: > I think we can do the old libevent for now as the trunk doesn't exploit the > new 2.0 features yet (though I have some implemented in a branch that is now > on hold). However, if we can fix shared memory quickly (and Sam appears to > have

Re: [OMPI devel] 1.5.x plans

On Oct 26, 2010, at 3:07 PM, Jeff Squyres wrote: > There seem to be 3 obvious options about moving forward (all assume that we > do 1.5.1 as described above): > > A. End the 1.5 line (i.e., work towards transitioning it to 1.6), and then > re-branch the trunk to be v1.7. > B. Sync the

[hwloc-devel] Create success (hwloc r1.1a1r2645)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.1a1r2645 Start time: Tue Oct 26 21:01:05 EDT 2010 End time: Tue Oct 26 21:03:08 EDT 2010 Your friendly daemon, Cyrador