8) linux/mips64 hangs in either atomic_spinlock or
atomic_spinlock_noinline test, depending on compiler and/or machine.
On 1/30/2012 7:55 PM, Paul H. Hargrove wrote:
Oh, I missed a big one:
7) opal/util/path.c has "#elif defined(linux)" but XLC does not define
this.
This is breaking test/uti
Good catch, for some reason the CMR of the patch I attached to ticket
#2977 didn't apply the CXX part. I've reopened the ticket asking Jeff
to apply that part of the patch :-).
Thanks,
--td
On 1/30/2012 6:17 PM, Paul H. Hargrove wrote:
I don't plan to rerun the dozens of different platforms
I blame the solar flares from last week.
We'll look at the remaining items from Paul's list (many thanks, Paul!) today
on the weekly call.
On Jan 31, 2012, at 5:42 AM, TERRY DONTJE wrote:
> Good catch, for some reason the CMR of the patch I attached to ticket #2977
> didn't apply the CXX part
Hello again.
I've found where the connection with the event logger takes places. I've
some doubts about the next section of code:
*rc = ompi_dpm.connect_accept(MPI_COMM_SELF, 0, port, true, el_comm);*
*if(OMPI_SUCCESS != rc) {*
*ORTE_ERROR_LOG(rc);*
*}*
*/* Send Rank, rece
Hot on the heels of rc3, rc4 is out:
http://www.open-mpi.org/software/ompi/v1.4/
The main differences are the 8 issues that Paul Hargrove mentioned:
Make v1.4 configure fail on OS X 10.3 and earlier
Fix opal/util/path.c for Linux with old compilers
README updates for the Sun compilers
REA
Looks like you /almost/ got it this time.
For opal/util/path.c you only fixed 1 out of 3 instances of defined(linux).
So, now it fails to compile ('buf' is undefined) rather than failing one
test at "make check".
And, by the way the fix you did apply:
"defined(linux) || defined(__linux) ||
On Jan 31, 2012, at 3:18 PM, Paul H. Hargrove wrote:
> Looks like you /almost/ got it this time.
>
> For opal/util/path.c you only fixed 1 out of 3 instances of defined(linux).
> So, now it fails to compile ('buf' is undefined) rather than failing one test
> at "make check".
Crud. Missed the o
You killed off many of my "corner case" platforms in the README, which
is good enough for me.
I've verified the gmake dependence (asm generation on BSD) has been fixed.
I've also confirmed that MacOS 10.3 is gracefully rejected by configure.
However, in addition to the reported "almost" on o
On Jan 31, 2012, at 3:48 PM, Paul H. Hargrove wrote:
>> 2) Must --disable-io-romio on OpenBSD
>
> Nobody has yet told me to shutup about that one, so I mention it here for
> completeness.
> Having looked only briefly at the failure, I see that it is in ROMIO's
> equivalent of opal_path_nfs().
>
On 1/31/2012 12:51 PM, Jeff Squyres wrote:
On Jan 31, 2012, at 3:48 PM, Paul H. Hargrove wrote:
2) Must --disable-io-romio on OpenBSD
Nobody has yet told me to shutup about that one, so I mention it here for
completeness.
Having looked only briefly at the failure, I see that it is in ROMIO'
Sorry to do this, but I've got another one:
I was looking over my reports against 1.5.5rc1 and came across:
http://www.open-mpi.org/community/lists/devel/2011/12/10184.php
In which "make clean" can fail on systems (mostly BSD) where make != gmake.
The issue is that $(RM) is defined by GNU Make b
On Jan 31, 2012, at 4:03 PM, Paul H. Hargrove wrote:
>> Oops -- Brad was supposed to put that in README, too.
>
> Nope, I looked:
> $ grep -i -e romio -e bsd openmpi-1.4.5rc4/README
>- Updated ROMIO to the version from MPICH2 1.0.7
Doh. :-\
> OK, "shutup" order confirmed regarding OpenBSD/
On Jan 31, 2012, at 4:26 PM, Paul H. Hargrove wrote:
> I think the fix is just "$(RM)" -> "rm", since bare "rm" is used pretty
> widely in other Makefile.am's.
Done.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cr
On 1/31/2012 1:42 PM, Jeff Squyres wrote:
On Jan 31, 2012, at 4:03 PM, Paul H. Hargrove wrote:
Oops -- Brad was supposed to put that in README, too.
Nope, I looked:
$ grep -i -e romio -e bsd openmpi-1.4.5rc4/README
- Updated ROMIO to the version from MPICH2 1.0.7
Doh. :-\
OK, "shutup
On Jan 31, 2012, at 4:53 PM, Paul H. Hargrove wrote:
> Which hwloc branch is destined for ompi-1.5.5?
> Once I known I can test the appropriate hwloc RC on all my platforms.
1.3.latest, so svn.open-mpi.org/svn/hwloc/branches/v1.3.
It's not that far from what is already in hwloc 1.5, but there we
On 1/31/2012 1:53 PM, Paul H. Hargrove wrote:
I can supply details if anybody want to work on this ahead of
1.5.5rc2, but the short report is:
gmake[3]: Entering directory
`/home/phargrov/OMPI/openmpi-1.5.5rc1-openbsd5-amd64/BLD/ompi/mca/io/romio/romio'
Making all in include
make: don't know
On Jan 31, 2012, at 6:17 PM, Paul H. Hargrove wrote:
> I took a quick look and discovered that all the generated Makefile's under
> ompi/mca/io/romio/romio contain explicit MAKE=make (twice per Makefile,
> actually).
I haven't gone back to look at 1.5.x yet -- but just to be clear, you're *no
On 1/31/2012 3:43 PM, Jeff Squyres wrote:
On Jan 31, 2012, at 6:17 PM, Paul H. Hargrove wrote:
I took a quick look and discovered that all the generated Makefile's under
ompi/mca/io/romio/romio contain explicit MAKE=make (twice per Makefile,
actually).
I haven't gone back to look at 1.5.x
18 matches
Mail list logo
