I did warn Jeff off-list at one point that I was planning/plotting to
automate my testing of RCs. Now you've seen the result of that.
Terry has been in contact on the Solaris issue.
On the GNU-vs-Berkeley make issue (bug #2954): the patch Jeff green lighted
has only been tested on FreeBSD and hy
More results:
PASS:
macos-10.7/gcc (llvm-gcc-4.2)
macos-10.7/clang (Apple clang version 3.0) - lots of warnings on
atomic_impl.h
These are the compilers that come w/ Xcode 4.2
FAIL:
macos-10.7/pgi-11.10
Fails as follows:
> Making all in tools/orte-clean
> source='../../../../orte/too
On Fri, Jan 27, 2012 at 5:34 AM, Jeff Squyres wrote:
[snip]
>
>
> I'm not quite sure how that can happen -- orte_odls appears to be
> prototyped properly in orte/mca/odls/odls.h (i.e., it has ORTE_DECLSPEC,
> for visibility), and is properly instantiated in
> orte/mca/odls/base/odls_base_open.c.
>
I can additionally report success w/ ILP32 builds with both SS12.2 and 12.3
compilers on x86-64 and sun4v systems running Solaris and x86-64/Linux:
solaris-10 Generic_137111-07/sun4v (*FLAGS="-m32 -xarch=sparc" for
v8plus ABI)
solaris-11 snv_151a/amd64 [incl. ofud, openib and dapl] (*FLAGS=-
On Tue, Feb 7, 2012 at 7:54 PM, Paul H. Hargrove wrote:
[snip]
> Of those 54:
> + 47 require nothing "extra" (just --prefix, CC & friends, and CFLAGS &
> friends for non-default ABIs)
>
[snip]
I found 5 more, making a total of 52 out of 59 configs that PASS with no
"extra" steps or configure opt
On Sat, Feb 11, 2012 at 10:12 PM, Paul H. Hargrove wrote:
>
>
> On 2/10/2012 6:04 PM, Jeff Squyres wrote:
>
>> On Feb 10, 2012, at 8:57 PM, Jeff Squyres wrote:
>>
>> 1.5.5rc2 coming soon.
>>>
>> I should qualify that statement: many things have been resolved, but
>> there's a few more things to g
I've configured the ompi trunk (nightly tarball 1.7a1r25927) on an SGI
Altix.
I used no special arguments indicating that this is an Altix, and there
does not appear to be an altix-specific file in contrib/platform.
My build fails as follows:
make: Entering directory
> `/mnt/home/c_phargrov/OMPI/
When trying to build the OMPI trunk or the 1.5 branch with clang-3.0, I
cannot build VT.
If have tried both MacOS 10.7 and FreeBSD-9.0-RELEASE.
In all four builds (2 branches X 2 OSes) the failure appears to be "deep"
in the C++ STL.
I strongly suspect that this is a Clang++ bug.
However, I am rep
See responses mixed in below.
On Wed, Feb 15, 2012 at 1:02 AM, Matthias Jurenz <
matthias.jur...@tu-dresden.de> wrote:
> Unfortunately, we don't have access to a PPC system with MacOS 10.4 to try
> to
> reproduce the error.
>
Not too surprising. I'll see what I can do to help resolve the probl
LD opal_wrapper
> ../../../opal/.libs/libopen-pal.so: undefined reference to
> `opal_timer_linux_freq'
> collect2: ld returned 1 exit status
It appears opal/mca/timer/altix was built, and opal/mca/timer/linux was not.
This is the reverse of the situation seen with the trunk.
-Paul
On Wed,
The following small patch was require to build the ompi trunk on NetBSD-5.0.
I am not sure if this was the proper header in which to add this include,
but it is the first one that needs "struct timeval".
-Paul
--- openmpi-1.7a1r25944/opal/dss/dss_types.h~ 2012-02-17
00:30:09.0 -0800
+++
OpenBSD lacks an aio.h header.
configure knows this:
> $ grep aio.h configure.log
> checking aio.h usability... no
> checking aio.h presence... no
> checking for aio.h... no
Yet fbtl/posix is enabled, despite needing aio.h:
> checking if MCA component fbtl:posix can compile... yes
I am guessi
I've confirmed that NO similar problem is present in the 1.5 branch.
-Paul
On Fri, Feb 17, 2012 at 12:49 AM, Paul Hargrove wrote:
> The following small patch was require to build the ompi trunk on
> NetBSD-5.0.
> I am not sure if this was the proper header in which to add this
Same has been seen on Solaris11/x86-64 w/ the Studio 12.3 compiler.
However, a gcc build on the same system was fine.
-Paul
On Fri, Feb 17, 2012 at 10:49 AM, Paul H. Hargrove wrote:
> Building last night's trunk tarball (1.7a1r25944) On Solaris10/SPARC w/
> Solaris Studio compilers if failing in
And here is the 10.7 machine as promised:
ProductName: Mac OS X
ProductVersion: 10.7.3
BuildVersion: 11D50b
lrwxr-xr-x 1 root wheel 12 Oct 27 14:01 /usr/bin/gcc -> llvm-gcc-4.2
-Paul
On Wed, Feb 22, 2012 at 7:44 PM, Paul H. Hargrove wrote:
> I can get exact info from my MacOS 10.7 machine l
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> On 23 Feb 2012, at 4:44 AM, Jeffrey Squyres wrote:
>
> I don't think I want to get specific about the gcc versions on any
>> platform, unless we know that they *don't* work. There
Am I the only one seeing the following odd behavior when running configure?
[...]
> *** GNU libltdl setup
> checking location of libltdl... internal copy
> configure: OMPI configuring in opal/libltdl
> []
> configure: creating ./config.status
> config.status: creating Makefile
> config.status:
Sat, Feb 25, 2012 at 11:28 PM, Ralph Castain wrote:
> No, I ran into it last week. The problem is that we don't handle spaces in
> path names - apparently, we never have, so far as Jeff could determine.
>
> On Feb 25, 2012, at 11:27 PM, Paul Hargrove wrote:
>
> Am I the on
ch.
So, I guess I've just encountered a known problem.
Since my scripts only do VPATH, you won't get any test results from me for
1.5.5rc2.
-Paul
P.S. I have no clue how a "make distcheck" could have completed with this
problem.
On Sun, Feb 26, 2012 at 12:32 AM, Paul Hargro
On Sun, Feb 26, 2012 at 6:37 AM, Ralph Castain wrote:
[snip]
> In the example you gave, the library you were adding ("dummy mt") has a
> space in it. We don't handle that case - that was my point.
>
But "dummy mt" was injected by the broken configure logic, not by me. It
was the SYMPTOM not the
I went ahead and tried Intel's latest compilers for MacOS 10.6.
They don't yet support MacOS 10.7.
All looks good w/ these compilers and the 1.5.5rc3 tarball.
I think this testing is too preliminary to consider this a "supported"
compiler.
-Paul
On Wed, Feb 22, 2012 at 6:57 PM, Paul H. Hargrove
Thanks, Jeff.
I agree that the vendor ID could push to 1.6, since an end-user can easily
edit the corresponding file post-install if needed (as opposed to source
changes).
For the other items I'll follow up in the ticket system if/when necessary.
-Paul
On Wed, Feb 29, 2012 at 10:35 AM, Jeffrey
The most likely reason for a "distcheck" to fail in this manner when a
checkout is fine would be a header not getting included in the tarball due
to some omission from Makefile.am
-Paul
On Tue, Jul 31, 2012 at 9:00 PM, Ralph Castain wrote:
> I'm not sure what to make of this one. I checked the
g. will take
> another look...
>
> On Jul 31, 2012, at 9:04 PM, Paul Hargrove wrote:
>
> The most likely reason for a "distcheck" to fail in this manner when a
> checkout is fine would be a header not getting included in the tarball due
> to some omission from Makefile.a
I have access to a few different Solaris machines and can offer to build
the trunk if somebody tells me what configure flags are desired.
-Paul
On Fri, Aug 24, 2012 at 8:54 AM, Ralph Castain wrote:
> Eugene - can you confirm that this is only happening on the one Solaris
> system? In other word
9a1r27092/ompi/tools/ompi_info'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory
> `/workspace/euloh/hpc/mtt-scratch/burl-ct-t2k-3/ompi-tarball-testing/mpi-install/s3rI/src/openmpi-1.9a1r27092/ompi'
> make: *** [install-recursive] Error 1
>
>
> On Aug 2
While trying to reproduce the "r27078 and OMPI build" problem w/ the Oracle
compilers, I hit the following unrelated problem instead:
Making all in otfaux
> make[9]: Entering directory
> `/shared/OMPI/openmpi-trunk-solaris11-x64-ib-ss12u3/BLD/ompi/contrib/vt/vt/extlib/otf/tools/otfaux'
> CXX
ent_completion_processing
mca_coll_ml_buffer_recycling
mca_coll_ml_memsync_intra
All of which are marked as "static inline __opal_attribute_always_inline__".
-Paul
On Fri, Aug 24, 2012 at 4:55 PM, Paul Hargrove wrote:
> OK, I have a vanilla configure+make
.
>
> On 8/24/2012 6:32 PM, Ralph Castain wrote:
>
> Thanks Paul!! That is very helpful - hopefully the ORNL folks can now fix
> the problem.
>
> On Aug 24, 2012, at 6:29 PM, Paul Hargrove wrote:
>
> I *can* reproduce the problem on SPARC/Solaris-10 with the SS12.3
I've not tested any other recent RCs, but had a chance today to run this
one on a subset of my normal pile of test platforms.
I am not sure why this has only hit me on NetBSD, because the problem looks
pretty generic.
When looking at
ompi/contrib/vt/vt/extlib/otf/tools/otfaux/Makefile.am
I find
i.org/community/lists/devel/2012/08/11446.php), but I
wonder what testing was conducted.
-Paul
On Tue, Sep 11, 2012 at 11:10 AM, Paul Hargrove wrote:
> I've not tested any other recent RCs, but had a chance today to run this
> one on a subset of my normal pile of test platforms.
>
While newer PGI compilers don't complain, I find that PGI-8.0-6 fails as
shown below.
In addition to 1 error, there are 3 warnings that might be worth
examination.
My guess is that the code is trying to use OMP features more recent than
the support provided by this older compiler.
However, OMPI's
In testing 1.6.2rc2 on a BG/Q front-end I've encountered the following
failure from "make check":
Failure : Mismatch: input "/soft", expected:0 got:1
> SUPPORT: OMPI Test failed: opal_path_nfs() (1 of 20 failed)
> FAIL: opal_path_nfs
What I find digging deeper is that the mount of /soft is a bi
Following-up as promised:
My build w/ PGI-7.2-5 has completed and produces the same error (and
warnings) as seen w/ 8.0-6 and reported in the message quoted below.
-Paul
On Tue, Sep 11, 2012 at 12:08 PM, Paul Hargrove wrote:
> While newer PGI compilers don't complain, I find that P
]
On Tue, Sep 11, 2012 at 12:40 PM, Ralph Castain wrote:
> Interesting - I can certainly fix the test so it lets make check complete.
>
> FWIW: I didn't know we were running on BG/Q - does it work? I assume this
> is with slurm?
>
> On Sep 11, 2012, at 12:34 PM, Paul Hargrov
stall them (even as non-root) and
use them w/ the license you have for 11.0.
-Paul
On Tue, Sep 11, 2012 at 12:48 PM, Bert Wesarg wrote:
> Hi,
>
> On Tue, Sep 11, 2012 at 9:38 PM, Paul Hargrove wrote:
> > Following-up as promised:
> > My build w/ PGI-7.2-5 has completed and pr
I have reported as long ago as 1.4.5rc2 (see
http://www.open-mpi.org/community/lists/devel/2012/01/10256.php ) that Open
MPI does not build with the Intel compilers (versions 9.1 and 10.0 tested)
on IA64.
This is still true with 1.6.2rc2, and I doubt anybody plans to fix this
soon, if ever.
HOWEVE
t is still possible if one gets ambitious.
-Paul
On Wed, Sep 12, 2012 at 7:38 AM, Jeff Squyres wrote:
> I just updated the test to check and see if we get a "none" type of
> filesystem. If so, we just skip it in the test.
>
>
> On Sep 11, 2012, at 3:50 PM, Paul Hargrove
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 fix on the older (and thus slower) PGI-7.2-5
platform which also displayed
:
> 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
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
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 compilers fr
Unless I am missing something here the desired incantation is either
"PUBLIC" to make an entire module's contents accessible, or "PUBLIC ::
[component]" for individual control.
PUBLIC should be a standard part of F95 (no configure probe required).
However, the presence of "OMPI_PRIVATE" suggests y
On Wed, Sep 26, 2012 at 10:56 PM, Jeff Squyres wrote:
[...]
> > However, the presence of "OMPI_PRIVATE" suggests you already have a
> configure probe for the "PRIVATE" keyword.
>
> Yes, we do, because not all compilers support it (yet?).
>
Then I'd guess you'll need to probe for "PUBLIC" too.
S
I am trying to resolve an odd issue I am seeing with my one uGNI-based
code, and was hoping to use OMPI's uGNI support as an example of correct
usage. My particular interest is in RDMA, but as far as I can tell the
uGNI blt in ompi-trunk doesn't have the btl_put or blt_get entry points.
So, if I
Thanks, Pasha. I see them now.
I asked precisely because I doubted that I have enough understanding of the
code structure to find this code on my own (and I did look). Obviously I
was right to doubt myself.
-Paul
On Mon, Oct 22, 2012 at 7:10 AM, Shamis, Pavel wrote:
> Paul,
>
> Did you look
On my FreeBSD-6.3/amd64 platform I see "make check" failing 3 tests under
test/datatype (see below). Of course "make" stops after that, making it
possible that additional tests might fail later.
However, my records do show that the v1.5 branch was just fine on this
machine, as was the trunk on or
-Paul
On Tue, Oct 30, 2012 at 8:13 PM, Paul Hargrove wrote:
> On my FreeBSD-6.3/amd64 platform I see "make check" failing 3 tests under
> test/datatype (see below). Of course "make" stops after that, making it
> possible that additional tests might fail later.
>
&
I have access to a Linux/x86-64 machine running "Red Hat Enterprise Linux
AS release 4"
It has a pretty old gcc:
$ gcc --version | head -1
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
As shown below, this gcc is rejecting some portion of the atomics.
I am certain I've tested ompi-1.5 and 1.6 on thi
I have a Linux/x86-64 system with PathScale's "ekopath-4.0.12.1" compilers.
Building Fortran 2008 support fails as shown below.
My records show the ompi-1.5 branch and a Feb 2012 trunk were OK on this
configuration.
-Paul
PPFC mpi-f08-interfaces-callbacks.lo
module mpi_f08_interfaces_ca
Linux/x86-64 host with Open64 compilers version 4.5.1 from AMD.
Fortran 2008 support is failing to build as shown below.
My records show the ompi-1.5 branch was fine on this configuration.
-Paul
PPFC mpi-f08-types.lo
^
openf95-855 openf90: ERROR MPI_F08_TYPES, File =
/global/homes
The problems I previously reported building the trunk with IBM's xlc/xlf:
http://www.open-mpi.org/community/lists/devel/2012/09/11518.php
is still present in OMPI-1.7.0rc5
-Paul
On Tue, Oct 30, 2012 at 7:01 PM, Ralph Castain wrote:
> Hi folks
>
> We have posted the next release candidate (rc
pathf95 from PathScale's 3.2.99 compiler suite fails in the same manner:
LOGICAL(KIND=4) not allowed with BIND(C)
-Paul
On Tue, Oct 30, 2012 at 9:03 PM, Paul Hargrove wrote:
> I have a Linux/x86-64 system with PathScale's "ekopath-4.0.12.1" compilers.
&g
Note that with Apple's latest versions of Xcode (4.2 and higher, IIRC)
Clang is now the default C compiler. I am told that Clang is the ONLY
bundled compiler for OSX 10.8 (Mountain Lion) unless you take extra steps
to install gcc (which is actually llvm-gcc and cross-compiles for OSX 10.7).
So, C
ns over
> these changes were from the national labs, so my point was that this
> discussion may all be irrelevant.
>
>
> On Oct 31, 2012, at 11:47 AM, Paul Hargrove wrote:
>
> Note that with Apple's latest versions of Xcode (4.2 and higher, IIRC)
> Clang is now the defau
issue of what is best for developers, then I tend
> to err on the side of generating warnings. However, those warnings must not
> appear for users when the code is in fact valid.
>
> The fact that some compilers do that is irrelevant - we are talking about
> what we want OMPI to do.
>
>
On Wed, Oct 31, 2012 at 12:16 PM, Dmitri Gribenko wrote:
> On Wed, Oct 31, 2012 at 9:11 PM, Paul Hargrove wrote:
> > Ralph,
> >
> > I work at a National Lab, and like many of my peers I develop/prototype
> > codes on my desktop and/or laptop. So, I think the default
On Wed, Oct 31, 2012 at 12:47 PM, Ralph Castain wrote:
>
> On Oct 31, 2012, at 12:36 PM, Paul Hargrove wrote:
>
> Ralph,
>
> I don't think I missed the point about the origin of the concern - we just
> have different view points.
>
> Jeff indicated that he previ
Santhosh,
I think Ralph wants you to give your definitions for "Marshlling" and
"Unmashalling".
Otherwise, it is not clear to him or others exactly what you are asking,
because there are multiple possible meanings for those terms.
-Paul
On Sun, Nov 4, 2012 at 7:56 PM, Santhosh Kokala <
santhosh.
On Wed, Nov 14, 2012 at 6:26 PM, Larry Baker wrote:
> m4 --version | sed -n -E -e
> '1s/^.*[^A-Za-z0-9_-]?([0-9]+[.][0-9]+[.][0-9]+)[^A-Za-z0-9_-]?.*$/\1/p'
>
There are STILL problems with this approach as it is TWICE specific to GNU
software:
1) M4 on OpenBSD (maybe others) doesn't support a
nd of version option. :-(
>
> I'll give Nathan a chance to work on this tonight. If we can't resolve the
> problem, I'll revert the m4 check as well.
>
>
> On Nov 14, 2012, at 5:41 PM, Paul Hargrove wrote:
>
> On Wed, Nov 14, 2012 at 6:26 PM, Larry Baker wrote:
>
ng of Ralph's
> "flex --version". Assuming the RE parser I wrote is satisfactory, it would
> have to be adapted to fit in the framework, i.e., it has to be portable.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
>
>
> On 14 N
Nathan,
What does this mean with respect to "clean up" and old flex?
Have you simply conceded that old flex will leak memory?
-Paul
On Thu, Dec 6, 2012 at 4:16 PM, Hjelm, Nathan T wrote:
> Done. We now clean up correctly in new flex while having support for old
> flex.
>
> -Nathan
--
Paul H
Surendra,
There is no "release" of gcc-4.8 yet, and my experience (not Open MPI
related) with recent snapshots has encountered many bugs still to be fixed
before any release. Even if you could build Open MPI with gcc-4.8, I would
not (at this time) trust it with any "production" jobs.
Looking at
Since I see OpenBSD twice on the list of changes, I've fired off my
automated testing on my OpenBSD platforms.
Since the "MPI datatype issues on OpenBSD" I reported against 1.7.0rc5 also
appeared on FreeBSD-6.3, I've tested that platform as well.
The good news is that the problems I've reported in
On Thu, Jan 17, 2013 at 2:26 PM, Paul Hargrove wrote:
[snip]
> The BAD news is a new failure (SEGV in orted at exit) on
> OpenBSD-5.2/amd64, which I will report in a separate email once I've
> completed some triage.
>
[snip]
You can disregard the "BAD news" above.
E
**
>
> ** **
>
> Ken
>
> ** **
>
> *From:* devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] *On
> Behalf Of *Paul Hargrove
> *Sent:* Thursday, January 17, 2013 4:58 PM
> *To:* Open MPI Developers
> *Subject:* Re: [OMPI devel] 1.6.4rc1 has been
On Thu, Jan 17, 2013 at 4:37 PM, Paul Hargrove wrote:
[snip]
> I just now ran tests on OpenBSD-5.2/i386 and OpenBSD-5.2/amd64, using
> Clang-3.1.
> Unfortunately, there is a mass of linker error building libmpi_cxx.la (on
> both systems)
> I am trying again with --disable-mpi-cxx
On Thu, Jan 17, 2013 at 5:36 PM, Paul Hargrove wrote:
> On Thu, Jan 17, 2013 at 4:37 PM, Paul Hargrove wrote:
> [snip]
>
>> I just now ran tests on OpenBSD-5.2/i386 and OpenBSD-5.2/amd64, using
>> Clang-3.1.
>> Unfortunately, there is a mass of linker error buildin
My employer has a nice new Cray XC30 (aka Cascade), and I thought I'd give
Open MPI a quick test.
Given that it is INTENDED to be API-compatible with the XE series, I began
configuring with
CC=cc CXX=CC FC=ftn --with-platform=lanl/cray_xe6/optimized-nopanasas
However, since this is Intel h/w,
is.
>
> George.
>
>
> On Jan 18, 2013, at 06:21 , Paul Hargrove wrote:
>
> My employer has a nice new Cray XC30 (aka Cascade), and I thought I'd give
> Open MPI a quick test.
>
> Given that it is INTENDED to be API-compatible with the XE series, I began
> conf
with it now.
>
> Hopefully, this will be the minimum required.
>
>
> On Jan 22, 2013, at 4:20 PM, Paul Hargrove wrote:
>
> I am using the openmpi-1.9a1r27886 tarball and I still see an error for
> one of the two duplicate symbols:
>
> CCLD orte
some reason
Note that this is a --disable-shared/--enable-static build which may differ
from other systems where LUSTRE support gets used/tested.
-Paul
On Fri, Jan 25, 2013 at 12:01 PM, Ralph Castain wrote:
> Thanks Paul
>
> I'm currently tracking down a problem on the Cray XE6 - it
ical bug to track this issue.
>
> Works in 1.7 :-/ ... If you add -lnuma to libs_static in
> mpicc-wrapper-data.txt.
>
> -Nathan
> HPC-3, LANL
>
> On Fri, Jan 25, 2013 at 02:13:41PM -0800, Paul Hargrove wrote:
> > Still having problems on the Cray XC30, but now they are when
Adding --without-lustre to my configure args allowed me to compile and link
ring_c.
I am in the queue now and will report later on run results.
-Paul
On Fri, Jan 25, 2013 at 2:13 PM, Paul Hargrove wrote:
> Still having problems on the Cray XC30, but now they are when linking an
> M
terall
> ;). mpicc is completely borked in the trunk.
>
> If you want to use the Cray wrappers with Open MPI I can give you a module
> file that sets up the environment correctly (link against -lmpi not
> -lmpich, etc).
>
> -Nathan
>
> On Fri, Jan 25, 2013 at 03:10:37PM -0
FYI:
I currently have QEMU-based ARM platform I use for testing other s/w:
+ a single-cpu ARMv5 system running Debian Squeeze
+ a dual-core ARMv7 system running Ubuntu Precise
Since these are EMULATED platforms, they are a bit on the slow side, making
periodic MTT runs untenable.
However, I
gt;
> So I'm not quite sure I understand the "mpicc is completely borked in the
> trunk". Can you elaborate?
>
> On Jan 25, 2013, at 3:59 PM, Paul Hargrove wrote:
>
> Nathan,
>
> The 2nd and 3rd non-blank lines of my original post:
>
>> Given that it is IN
corresponding dirs:
-L/opt/cray/xpmem/default/lib64 -L/opt/cray/ugni/default/lib64
Note that I configured using --without-lustre this time, or its libs might
have been needed as well.
-Paul
On Fri, Jan 25, 2013 at 4:53 PM, Ralph Castain wrote:
>
> On Jan 25, 2013, at 4:29 PM, Paul Ha
Ralph,
Those are the result of the missing -lnuma that Nathan already identified
earlier as missing in BOTH 1.7 and trunk.
I see MORE missing symbols, which include ones from libxpmem and libugni.
-Paul
On Fri, Jan 25, 2013 at 4:59 PM, Ralph Castain wrote:
>
> On Jan 25, 2013, at 4:53 PM, Ral
proper fix.
-Paul
On Fri, Jan 25, 2013 at 5:45 PM, Ralph Castain wrote:
>
> On Jan 25, 2013, at 5:12 PM, Paul Hargrove wrote:
>
> Ralph,
>
> Those are the result of the missing -lnuma that Nathan already identified
> earlier as missing in BOTH 1.7 and trunk.
> I see MOR
While building 1.7rc6 on a i386 w/ InfiniBand I saw numerous instances of
this warning:
../../../../../orte/mca/oob/ud/oob_ud.h:93: warning: cast from pointer
to integer of different size
The following 1-line change fixes this.
Alternatively, a single cast to type uintptr_t is probably sufficie
sts/1.0-1.0401.35364.1.115.gem30) eswrap/1.0.10
14) configuration/1.0-1.0401.35391.1.2.gem 31) xtpe-mc12
15) ccm/2.2.0-1.0401.37254.2.14232) cray-shmem/5.6.0
16) audit/1.0.0-1.0401.37969.2.32.gem 33) PrgEnv-gnu/4.1.40
17) rca/1.0.0-2.0401.38656.2.2.gem
-Paul
On Fri, Jan 2
I am pleased to say that 1.6.4rc2 builds and runs (single node, sm btl) on
my BSD menagerie:
freebsd6-amd64
freebsd7-amd64
freebsd8-amd64
freebsd8-i386
freebsd9-amd64
freebsd9-i386
netbsd6-amd64
netbsd6-i386
openbsd5-amd64
openbsd5-i386
The {Free,Net,Open}BSD platform
ust fine for me once built that way.
> >>
> >> So I'm not quite sure I understand the "mpicc is completely borked in
> the trunk". Can you elaborate?
> >>
> >> On Jan 25, 2013, at 3:59 PM, Paul Hargrove wrote:
> >>
> >>
When configured using --with-ft=cr on linux/x86 I see the following build
failure:
Making all in mca/errmgr
make[2]: Entering directory
`/home/pcp1/phargrov/OMPI/openmpi-1.7rc6-linux-x86-blcr/BLD/orte/mca/errmgr'
CC base/errmgr_base_close.lo
CC base/errmgr_base_select.lo
CC
The following 2 fragment from config/orte_check_alps.m4 appear to be
contradictory.
By that I mean the first appears to mean that "--with-alps" with no
argument means /opt/cray/alps/default/... for CLE5 and /usr/... for CLE4,
while the second fragment appears to be doing the opposite:
lph Castain wrote:
> Yes, we need to make it absolutely clear that c/r is no longer supported -
> I'll remove that configure option.
>
> Thanks
> Ralph
>
> On Jan 28, 2013, at 5:38 PM, Paul Hargrove wrote:
>
> When configured using --with-ft=cr on linux/x86 I see t
, the defaults for orte_check_alps_dir should be
exchanged to yield:
CLE4:
orte_check_alps_libdir="/usr/lib/alps"
orte_check_alps_dir="/usr"
CLE5:
orte_check_alps_libdir="/opt/cray/alps/default/lib64"
orte_check_alps_dir="/opt/cray/alps/default"
-Pa
Mon, Jan 28, 2013 at 6:30 PM, Ralph Castain wrote:
> Like I said, I didn't write this code - all I can say for certain is that
> it gets the right answer on the LANL Crays. I'll talk to Nathan (the
> author) about it tomorrow.
>
> On Jan 28, 2013, at 6:23 PM, Paul Hargrove w
the
job.
Again, this probably slipped past Nathan because under CLE4 the alps
headers are under /usr/include and therefore the missing CPPFLAGS were not
actually required.
-Paul
On Mon, Jan 28, 2013 at 7:05 PM, Paul Hargrove wrote:
> Ralph and Nathan,
>
> As I said, the results I see
Using tonight's trunk tarball (r27954) configured using
"--with-devel-headers" it looks like "make install" is trying to install
rte_orte.h TWICE:
/usr/bin/install -c -m 644 ../../../../../ompi/mca/rte/orte/rte_orte.h
> ../../../../../ompi/mca/rte/orte/rte_orte.h
> '/global/homes/h/hargrove/GSCR
OK, I am now on the openmpi-1.9a1r27954 tarball.
In order to build OMPI and compile apps on this machine I must
1) edit the xe6 platform to --disable-shared/--enable-static (site-specific)
2) edit the xe6 platform file to provide a full path to the alps headers
because the logic in orte_check_alp
Sounds like the problem comes down to just 32-bit systems that fault on
unaligned 8-byte loads.
That would be SPARC, IA64 and MIPS. For IB only SPARC is relevant.
So perhaps alignment>2 should be conditional on 32-bit SPARC target.
Additionally, an experiment to see if 4-byte alignment is "good e
Pasha,
I have at least one system where I can reproduce the problem, but don't
have up-to-date autotools.
So, I can only test from a tarball.
If somebody can roll me a tarball of r28289 I can test ASAP.
Otherwise I'll try to remember to test from tonight's trunk nightly once it
appears.
-Paul
New tarball is on the website now and I've started my build...
-Paul
On Thu, Apr 4, 2013 at 2:15 PM, Ralph Castain wrote:
> I can kick it off now - will take a little while to hit the web site.
>
>
> On Apr 4, 2013, at 2:01 PM, Paul Hargrove wrote:
>
> Pasha,
>
&g
Paul,
> >
> > I will prepare a tarball for you.
> >
> > Thanks !
> >
> > Pavel (Pasha) Shamis
> > ---
> > Computer Science Research Group
> > Computer Science and Math Division
> > Oak Ridge National Laboratory
> >
> >
> >
-Paul
On Thu, Apr 4, 2013 at 5:52 PM, Ralph Castain wrote:
> Thanks Paul!!
>
> As always, much appreciated.
>
> On Apr 4, 2013, at 4:41 PM, Paul Hargrove wrote:
>
> Pasha,
>
> Your fix appears to work.
>
> My previous testing that reproduced the problem was agains
On Wed, Apr 17, 2013 at 10:40 AM, Orion Poplawski wrote:
> So, would you be willing to provide more of the rationale as to why
> libevent is bundled?
Orion,
I am NOT an Open MPI developer myself. So please don't take my response as
speaking for the community.
I found the following file usefu
Eric,
Are you testing against the Open MPI svn trunk?
I ask because on April 9 George commited a fix for the bug reported
by Thomas Jahns:
http://www.open-mpi.org/community/lists/devel/2013/04/12268.php
-Paul
On Tue, Apr 23, 2013 at 5:35 PM, Eric Chamberland <
eric.chamberl...@giref.ulaval
1 - 100 of 925 matches
Mail list logo
