Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.5.1rc1r4830
Start time: Thu Sep 13 21:04:53 EDT 2012
End time: Thu Sep 13 21:08:31 EDT 2012
Your friendly daemon,
Cyrador
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.6a1r4837
Start time: Thu Sep 13 21:01:01 EDT 2012
End time: Thu Sep 13 21:04:53 EDT 2012
Your friendly daemon,
Cyrador
An earlier release of the XL compilers (XLC-11.1 and XLF-13.1) on a
different host *also* displays the same errors.
-Paul
On Thu, Sep 13, 2012 at 2:33 PM, Paul Hargrove wrote:
> I've just tried building the Open MPI Trunk on a PPC64/Linux node using
> the May 2012 XL
I've just tried building the Open MPI Trunk on a PPC64/Linux node using the
May 2012 XL compilers from IBM (XLC-12.1 and XLF-14.1)
While I CAN build the 1.6.2 rc's, a build of the trunk is failing in the
F90 bindings as shown at the end of this message.
While MOST errors are "1513-230", note that
Matthias,
Maybe we are failing to communicate?
I said the problem is FIXED for PGI-7.2-5 (but did have the problem in rc2).
The system w/ PGI-8.0 was unavailable for running of the test.
Do you still want me to retest on PGI-7.2-5?
-Paul
On Thu, Sep 13, 2012 at 3:37 AM, Matthias Jurenz
On Sep 12, 2012, at 8:16 PM, Paul Hargrove wrote:
> Finally, Jeff's fix to "loosen" the opal_nfs_path test to ignore
> type==none (e.g. for bind-mounts) doesn't appear to be in this rc -
> the file test/util/opal_path_nfs.c is unchanged relative to rc2.
> Perhaps a CMR is in order? Perhaps it
On Wednesday 12 September 2012 17:16:48 Paul Hargrove wrote:
> Solaris and NetBSD platforms which displayed the VT Makefile error w/
> 1.6.2rc2 have completed successful builds w/ 1.6.2rc3.
>
> The PGI-8.0 platform which showed the other VT problem is down at the
> moment. So, I've tested that
Le 05/09/2012 17:42, Jeff Squyres a écrit :
> On Sep 5, 2012, at 11:36 AM, Samuel Thibault wrote:
>
>>> 1. We do not allow "./configure --enable-static --enable-shared". Even
>>> though that's valid Automake/Libtool (i.e., it'll generate libhwloc.a *and*
>>> libhwloc.so), we don't allow it.
>>