[OMPI devel] [2.0.0rc2] run failure on OpenBSD5-i386

With OpenBSD-5.9 on x86 (but *not* amd64) when I try to run an application built with Open MPI 2.0.0rc2, I get a SEGV before any output: $ mpirun -mca btl sm,self -np 2 examples /ring_c' -- mpirun noticed that process rank 1

[OMPI devel] [2.0.0rc2] Illegal instruction on Pentium III

I have an Pentium III Linux system which fails "make check" with: make[3]: Entering directory `/home/phargrov/OMPI/openmpi-2.0.0rc2-linux-x86-OpenSuSE-10.2/BLD/ompi/debuggers' make[4]: Entering directory `/home/phargrov/OMPI/openmpi-2.0.0rc2-linux-x86-OpenSuSE-10.2/BLD/ompi/debuggers' PASS:

[OMPI devel] [2.0.0rc2] ppc SEGVs

Running in several different PPC platforms I see "make check" fail as follows: make[4]: Entering directory `/home/phargrov/OMPI/openmpi-2.0.0rc2-linux-ppc32-gcc/BLD/ompi/debuggers' PASS: predefined_gap_test PASS: predefined_pad_test

[OMPI devel] [2.0.0rc2] "make check" failure on ARMv6

Running on a Raspberry Pi w/ Debian Jessie. A "make check" fails with a SEGV in the dl_open test. The output is pretty much the same as my previous 2 reports for other architectures: make[4]: Entering directory '/home/phargrov/OMPI/openmpi-2.0.0rc2-linux-arm-rpi/BLD/ompi/debuggers' PASS:

Re: [OMPI devel] [2.0.0rc2] build failure with ppc64 and "gcc -m32" (hwloc)

FWIW, this problem does not occur with Open MPI 1.10.2 on the same system and configured identically. -Paul On Mon, May 2, 2016 at 12:53 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I have a linux/ppc64 host running Fedora 20. > I have configured the 2.0.0rc2 tarball with

[OMPI devel] [2.0.0rc2] xlc build failure (inline asm)

It appears that xlc's support for gcc-style inline asm does not allow an empty clobbers list. The failure I see is libtool: compile: xlc -DHAVE_CONFIG_H -I. -I/home/hargrove/SCRATCH/OMPI/openmpi-2.0.0rc2-linux-ppc64-xlc-12.1/openmpi-2.0.0rc2/opal/asm -I../../opal/include -I../../ompi/include

[OMPI devel] [2.0.0rc2] xlc build failure (pmix)

AFTER fixing the inline asm problem detailed in https://www.open-mpi.org/community/lists/devel/2016/05/18886.php, I still cannot build with xlc. The issue arises in the pmix code and originates from a disagreement between pmix_hash_table.h and pmix_hash_table.c. The header declares 8 functions

[OMPI devel] [2.0.0rc2] misleading error message from configure

I can see why no competent OMPI developer ever encountered the following cut-and-paste error: diff --git a/config/opal_mca.m4 b/config/opal_mca.m4 index 1ec342c..d3a7075 100644 --- a/config/opal_mca.m4 +++ b/config/opal_mca.m4 @@ -86,7 +86,7 @@ AC_DEFUN([OPAL_MCA],[ if test

[OMPI devel] [2.0.0rc2] NetBSD build failure (ompio)

On NetNSD-7 I am testing PR1128 to get past an issue Nathan fixed since my report earlier today (Monday). It appears that OMPIO is not prepared for NetBSD's uses of statvfs() instead of statfs(). The error message appear at the bottom of this email. FWIW the ROMIO code does have the necessary

[OMPI devel] [2.0.0rc2] build failures on OpenBSD-5.7 (romio)

This is NOT a new issue, but I wanted to mention it explicitly once again since no progress has been made since I first reported to problem in 1.8.6rc1 (about 1 year ago). Though the directory name and line numbers have changed, the error reported in

Re: [OMPI devel] [2.0.0rc2] build failure with ppc64 and "gcc -m32" (hwloc)

hwloc/commit/9549fd59af04dca2e2340e17f0e685f8c552d818 > Thanks for the report > Brice > > > > > Le 02/05/2016 21:53, Paul Hargrove a écrit : > > I have a linux/ppc64 host running Fedora 20. > I have configured the 2.0.0rc2 tarball with > > --prefix=[] --en

[OMPI devel] [2.0.0rc2] ICE with ekopath-5 and 6

With the ekopath (aka pathscale) 5.0.5 and 6.0.527 compilers I get an ICE (Internal Compiler Error) building this rc. While this is clearly not an OMPI bug, it may be worth recording in the README. The (different) errors for these two compilers are shown below. -Paul libtool: compile: pathcc

[OMPI devel] [2.0.0rc2] NAG Fortran support still broken

For the record: When last we communicated on the issue of supporting FC=nagfor the milestone was set at 1.10.3 (issue #1284). While Gilles did make some progress, several of the same things reported originally are still broken in 2.0.0rc2 (and presumably in master and v1.10). -Paul -- Paul H.

[OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

For possible inclusion in README: xlc-13.1.0 on Linux dies compiling the embedded hwloc in this rc (details below). The same is true of the released hwloc 1.11.3 -Paul libtool: compile: xlc -DHAVE_CONFIG_H -I.

Re: [OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

e are just reporting gcc results) > > Thanks, > Josh > > > On Tue, May 3, 2016 at 3:11 AM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> For possible inclusion in README: >> xlc-13.1.0 on Linux dies compiling the embedded hwloc in this rc (details >>

Re: [OMPI devel] [2.0.0rc2] xlc build failure (inline asm)

:48PM -0500, Josh Hursey wrote: > >Did someone pick this up to merge into master & v2.x? > >I can confirm that Paul's patch fixes the issue for XL compilers. I > didn't > >see a PR for it, but can file one if no one has yet. > >On Mon,

[OMPI devel] [PATCH] Fix for xlc-13.1.0 ICE (hwloc)

I have some good news: I have a fix!! FWIW: I too can build w/ xlc 12.1 (also BG/Q). It is just the 13.1.0 on Power7 that crashes building hwloc. Meanwhile, 13.1.2 on Power8 little-endian does not crash (but is a different front-end than big-endian if I understand correctly). I started

Re: [OMPI devel] [2.0.0rc2] build failures on OpenBSD-5.7 (romio)

t; > > Cheers, > > > Gilles > > On 5/3/2016 2:21 PM, Paul Hargrove wrote: > > This is NOT a new issue, but I wanted to mention it explicitly once again > since no progress has been made since I first reported to problem in > 1.8.6rc1 (about 1 year ago). > >

[OMPI devel] [v2.x] more "patcher" issues

I am testing a tarball built from v2.x-dev-1410-g81e0924 This includes pull request #1128 in which Nathan addressed multiple "patcher" issues. However, I see the crash below in dlopen_test on a LITTLE-ENDIAN Power8 system. This is happening when built with "V13.1.2 (5725-C73, 5765-J08)", but not

Re: [OMPI devel] [v2.x] more "patcher" issues

inux-ppc64-xlc-13.1/openmpi-gitclone/ompi/debuggers/dlopen_test.c:97 #6 0x100010d8 in main (argc=1, argv=0x462f398) at /gpfs-biou/phh1/OMPI/openmpi-v2.x-dev-1410-g81e0924-linux-ppc64-xlc-13.1/openmpi-gitclone/ompi/debuggers/dlopen_test.c:135 On Fri, May 6, 2016 at 9:14 AM, Pau

[OMPI devel] [v2.x] Harmless type conversion warnings from Clang

I don't think any of the warnings below indicate errors. However, each could probably be suppressed with an appropriate cast. -Paul /scratch/phargrov/OMPI/openmpi-v2.x-dev-1410-g81e0924-linux-x86_64-clang/openmpi-gitclone/opal/mca/memory/patcher/memory_patcher_component.c:370:34: warning:

[OMPI devel] [v2.x] printf format warnings w/ -m32

The 96 printf format warnings in the attachment come from an Linux/x86-64 system w/ Clang and "-m32". Some of the warnings are "size_t" vs "unigned long", which is harmless since both are 32-bits. However, there are several cases in sharedfp/sm where a 64-bit (long long) format has a 32-bit

[OMPI devel] [2.0.0rc2] opal/mca/timer/aix?

I see opal/mca/timer/aix is still around in 2.0.0rc2. Does that mean Open MPI is expected to run on AIX, or is this directory an orphan? I have access to AIX-7.1.3 on Power7 h/w, and found that 2.0.0rc does NOT build there out of the box. Does anybody care? -Paul -- Paul H. Hargrove

[OMPI devel] [2.0.0rc] memory:patcher fragility

I noticed that opal/mca/memory/patcher/memory_patcher_component.c includes without ever checking (not even in the .m4 fragment) that this header exists. At the moment, AIX is the only O/S I've encountered that doesn't have a sys/syscall.h. However, I think the possibility of others needs to be

[OMPI devel] Master broken for ILP32

Perhaps this is already known. Several builds I've tried recently from the ompi (not ompi-release) repo are failing on 32-bit platforms with ../../../opal/.libs/libopen-pal.so: undefined reference to `__sync_add_and_fetch_8' This is impacting PRs that I am being asked to test (e.g. 1643).

Re: [OMPI devel] Master broken for ILP32

on 64 bits (!) > > > Cheers, > > > Gilles > > On 5/9/2016 3:59 PM, Paul Hargrove wrote: > > Perhaps this is already known. > Several builds I've tried recently from the ompi (not ompi-release) repo > are failing on 32-bit platforms with >../../../opal/.libs/

[OMPI devel] [v2.x] opal_list debug ref-count bug?

I am currently working with the v2.x branch, rather than tarballs. While attempting to build on AIX (which is ILP32 by default), I encountered an unexpected undefined reference to __sync_add_and_fetch_8() from opal/class/opal_list.h. I found that when debugging is enabled (as in almost every

Re: [OMPI devel] [v2.x] opal_list debug ref-count bug?

bits atomic detection in the config.log and > post here the corresponding output ? > > Thanks, > George. > > > > On Tue, May 10, 2016 at 1:38 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> I am currently working with the v2.x branch, rather than

Re: [OMPI devel] [v2.x] opal_list debug ref-count bug?

ve the unnecessary code (from the switch case with a > const), then we will [wrongfully] generate the stub for calling the 64 bits > atomic operation. > > George. > > > > On Tue, May 10, 2016 at 3:48 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> George,

Re: [OMPI devel] [2.0.0rc2] build failure on Linux w/ studio 12.x and -m32

"xchgl %%ebx, %1\n" "rdtsc\n" : "=A"(ret), "=r"(tmp) :: "ecx"); On Mon, May 2, 2016 at 1:48 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > The 2.0.0r

Re: [OMPI devel] [v2.x] printf format warnings w/ -m32

g> wrote: > I took a look at this, and the problem isn’t in the print statements. The > problem is that PRIsize_t is being incorrectly set to “unsigned long” > instead of something correct for the -m32 directive in that environment > > > On May 6, 2016, at 9:48 AM, Paul Hargrov

Re: [OMPI devel] Use non-cpu frequency for timers

Abhishek, That frequency variable doesn't need to be the CPU frequency. If you look at opal/mca/timer/linux/timer_linux_component.c:opal_timer_linux_find_freq() you will see the initialization for opal_timer_linux_freq. In the case of PPC the time stamp counter runs at a frequency, distinct from

[OMPI devel] [1.10.3rc2] OpenBSD build failure

As before, this RC cannot build ROMIO on OpenBSD 5.7 and higher. Unlike previous times that I've reported this issue, Gilles now has a fix available. However, it it currently stuck in a PR for master: https://github.com/open-mpi/ompi/pull/1643 Not a high priority, but thought I mention it. -Paul

[OMPI devel] [1.10.3rc2] Build failure with Studio 12.5-beta

The Solaris Studio 12.5 Fortran compiler is not being identified correctly by libtool. This is the same problem described for 2.0.0rc2 in https://www.open-mpi.org/community/lists/devel/2016/05/18949.php That email includes a patch that Gilles turned into a PR:

Re: [OMPI devel] [1.10.3rc2] OpenBSD build failure

ch folks before I commit it into > master and PR to the release branches. > I am fine to merge it and pr now if needed > > Cheers, > > Gilles > > > On Saturday, May 21, 2016, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> As before, this RC cannot build

[OMPI devel] [1.10.3rc2] testing summary

Overnight my (relatively) slow ARM and MIPS testers completed. Most of those have been moved to real hardware (vs QEMU) and I've been able to increase coverage as a result. I will note that I was not able to test IA64 (yet?) because that system is down. I've emailed the owners of that system and

Re: [OMPI devel] [1.10.3rc2] testing summary

On Sat, May 21, 2016 at 3:14 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I did encounter one issue that still needs more investigating before I can > attribute it to Solaris or to Open MPI: > Since I last built Open MPI there x86-64/Solaris systems were updated from >

Re: [OMPI devel] [1.10.3rc2] testing summary

On Sat, May 21, 2016 at 3:14 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I will note that I was not able to test IA64 (yet?) because that system is > down. > I've emailed the owners of that system and am hopeful that I can test it > in the next few days. > The IA64 tests

[OMPI devel] [1.10.3rc3] Linux static link failure of fortran examples

The following error did *not* occur on the same system with the previous RC. I have configured 1.10.3rc3 on a normal x86-64/Linux system with: --prefix=[...] --enable-debug --enable-static --disable-shared When I try to use the resulting build to compile the examples: $ make -k mpicc -g

Re: [OMPI devel] [1.10.3rc3] Linux static link failure of fortran examples

n-mpi/ompi-release/pull/1191 i am still testing > > (it also fixes a typo in pthread_join invokation) > > > Cheers, > > > Gilles > > > > On 5/25/2016 2:15 PM, Paul Hargrove wrote: > > The following error did *not* occur on the same system with the previous &g

[OMPI devel] [1.10.3.rc3] test results summary

Sometime earlier today while I was busy in meetings, my tests of the 1.10.3rc3 tarball completed. The two issues I had reported in RC2 did not occur with RC3. The issue with static linking of Fortran was the only issue I encountered, and I believe that Gilles' PR to fix that has already been

[OMPI devel] [1.10.3rc4] testing results

I am pleased to report SUCCESS on 93 out of 95 distinct test configurations. The two failures were NAG Fortran versions 5 and 6, which were not expected to work with v1.10. The NAG support is being tracked in issue #1284, and the work (PR 1295) was merged to master just minutes ago. While the

Re: [OMPI devel] Open MPI v2.0.0rc3 now available

e. > > - Fix MPI_IREDUCE_SCATTER_BLOCK for a one-process communicator. Thanks >to Lisandro Dalcin for reporting. > > - Fix detection and use of Solaris Studio 12.5 (beta) compilers. >Thanks to Paul Hargrove for reporting and debugging. > > - Allow NULL arrays when creati

[OMPI devel] [2.0.0rc3] ppc64el/XLC crash in intercept_mmap()

On a little-endian Power8 with XLC-13.1.2 I see a crash not seen with gcc-4.9.2: make[4]: Entering directory '/home/phargrov/OMPI/openmpi-2.0.0rc3-linux-ppc64el-xlc/BLD/ompi/debuggers' PASS: predefined_gap_test PASS: predefined_pad_test

[OMPI devel] [2.0.0rc3] NAG Fortran failures

I am seeing the following errors when using NAG Fortran (v5 or v6): Error: /sandbox/hargrove/OMPI/openmpi-2.0.0rc3-linux-x86_64-nagfor-5/openmpi-2.0.0rc3/ompi/mpi/fortran/use-mpi-tkr/mpi_comm_spawn_multiple_f90.f90: Argument 3 to MPI_COMM_SPAWN_MULTIPLE has data type DOUBLE PRECISION in reference

Re: [OMPI devel] [2.0.0rc3] ppc64el/XLC crash in intercept_mmap()

Also seen now on a big-endian Power7 with XLC-13.1 -Paul On Wed, Jun 15, 2016 at 6:20 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > On a little-endian Power8 with XLC-13.1.2 I see a crash not seen with > gcc-4.9.2: > > make[4]: Entering directory > '/home/phargrov/OMPI/o

[OMPI devel] [2.0.0rc3] Solaris Studio Linux/x86-64 and -m32

I still see the issue I (re)reported against the previous RC in https://www.open-mpi.org/community/lists/devel/2016/05/18961.php -Paul -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department

[OMPI devel] [2.0.0rc3] build failure on ppc32 and arm

The same failure mode reported below is also occurring on a 32-bit ARM system. -Paul On Wed, Jun 15, 2016 at 6:13 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > With a PPC64/Fedora20/gcc-4.8.3 system configuring for "-m32": > > configure --prefix=[...] --enable-debu

Re: [OMPI devel] [2.0.0rc3] NAG Fortran failures

was added in https://github.com/open-mpi/ompi/pull/1295 > > Milestone was set to v2.0.1 so no PR was even issued (yet) for the v2.x > branch. > > If there is a consensus to update the milestone to v2.0.0, i ll be happy > to PR > > > Cheers, > > > Gilles > >

[OMPI devel] [2.0.0rc3] regression: not enough space for shared memory-backing file

I am testing the 2.0.0rc3 tarball PLUS the patch from PR1232 to fix the dependence on 64-bit atomics. On an ARM system with only 256MB of memory, I am seeing the following failure which did NOT occur in my testing of 1.10.3rc4. $ mpirun -mca btl sm,self -np 2 examples/ring_c'

Re: [OMPI devel] [2.0.0rc3] regression: not enough space for shared memory-backing file

, Paul Hargrove <phhargr...@lbl.gov> wrote: > I am testing the 2.0.0rc3 tarball PLUS the patch from PR1232 to fix the > dependence on 64-bit atomics. > On an ARM system with only 256MB of memory, I am seeing the following > failure which did NOT occur in my testing of 1.10.3rc4. &

Re: [OMPI devel] v2.0.0rc4 is released

I am afraid that the rain dances might not have been effective, perhaps because July in San Francisco is already so cold and damp. My inbox is slowly accumulating sad-panda reports from my tests. I will report details when I am at a full-sized screen and keyboard. -Paul [Sent from my phone] On

[OMPI devel] [2.0.0rc4] non-critical faulres report

The following are previously reported issues that I am *not* expecting to be resolved in 2.0.0. However, I am listing them here for completeness. Known, but with later target: OpenBSD fails to build ROMIO - PR1178 exists with v2.0.1 target NAG Fortran support - PR1215 exists with v2.0.1 target

[OMPI devel] [2.0.0rc4] dlopen_test crash with xlc

The issue reported in https://www.open-mpi.org/community/lists/devel/2016/06/19107.php is still present on both my little-endian Power8 and big-endian Power7 systems. I know Nathan had been working on this, but I've lost track of the issue and/or pr number(s). -Paul -- Paul H. Hargrove

[OMPI devel] [2.0.0rc4] check failure with Linux Studio Compilers and -m32

I have the Sun/Oracle Studio compilers installed on Linux/x86-64 systems. I test versions 12.2 and 12.4 with "-m32". I both of those builds "make check" is failing with a SEGV from dlopen_test. This is an improvement over the previous rc3, which did not build at all. >From the core file on the

Re: [OMPI devel] [2.0.0rc4] dlopen_test crash with xlc

using XLC 13.1.3 on that > system and we haven't been runing 'make check'. I have another system that > has XLC 13.1.2 that I can test on as well. I'm not sure if I'll be able to > fix without Nathan's help, but I can at least try to reproduce. > > Thanks, > Josh > > > O

Re: [OMPI devel] [2.0.0rc4] non-critical faulres report

wn the versions of the PGCC where you get the ICE when > using the -m32 option? > > Thanks, > > Howard > > > 2016-07-06 15:29 GMT-06:00 Paul Hargrove <phhargr...@lbl.gov>: > >> The following are previously reported issues that I am *not* expecting to >&

Re: [OMPI devel] [2.0.0rc4] non-critical faulres report

I have a lead on a 15.10 installation with -m32 support. I will report results later. -Paul On Tue, Jul 12, 2016 at 10:29 AM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > Got it; thanks. > > > On Jul 12, 2016, at 1:00 PM, Paul Hargrove <phhargr...@lbl.gov> wr

Re: [OMPI devel] [2.0.0rc4] non-critical faulres report

Ok, PGI 15.10 w/ -m32 failed in the same way as the earlier versions. -Paul On Tue, Jul 12, 2016 at 11:10 AM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I have a lead on a 15.10 installation with -m32 support. > I will report results later. > > -Paul > > > On Tu

Re: [OMPI devel] Change compiler

Murali, I typically configure with CC=clang CXX=clang++ on the configure command line. Editing of the files generated by configure (such as the Makefile) is not advisable. -Paul On Mon, Jul 18, 2016 at 1:06 PM, Emani, Murali wrote: > Hi all, > > I would like to know if

Re: [OMPI devel] PGI built Open MPI vs GNU built slurm

Gilles, My initial thought is that libslurm probably does require linking libpthread, either for for linking pthread_* symbols, or for proper *operation* (such as thread-safe versions of functions which override weak definitions in libc). If so, then neither omitting "-pthread" nor telling pgcc

Re: [OMPI devel] PGI built Open MPI vs GNU built slurm

linking. > > since -lpthread is pulled anyway from libslurm.la (or it was already set > by OpenMPI), then yes, discarding -pthread should do the trick. > > > Cheers, > > > Gilles > > On 7/26/2016 10:11 AM, Paul Hargrove wrote: > > Gilles, > > My in

Re: [OMPI devel] 1.4.5rc2 test results

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

[OMPI devel] 1.4.5rc2 tests on MacOSX Lion (2 pass, 1 FAIL)

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 >

Re: [OMPI devel] 1.4.5rc2 tests on MacOSX Lion (2 pass, 1 FAIL): orte_odls visibility issue

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 >

[OMPI devel] 1.4.5rc2 more Solaris Studio compiler results

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]

Re: [OMPI devel] 1.4.5rc5 has been released

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"

Re: [OMPI devel] 1.5.5rc2r25906 test results

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

[OMPI devel] trunk build failure on Altix

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 >

[OMPI devel] VT build failure with Clang++

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

Re: [OMPI devel] 1.5.5rc1 tested: MacOS/ppc (w/ 1 failure and a "CMR")

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

[OMPI devel] 1.5 branch build failure on Altix

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, Feb 15, 2

[OMPI devel] trunk build failure on NetBSD-5.0

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

[OMPI devel] trunk build failure on OpenBSD-5.0

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

Re: [OMPI devel] trunk build failure on NetBSD-5.0

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 <phhargr...@lbl.gov> 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

Re: [OMPI devel] Solaris/SOS build failure in trunk

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

Re: [OMPI devel] 1.5 supported systems

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

Re: [OMPI devel] 1.5 supported systems

; > 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's too many

[OMPI devel] Odd build breakage seen with 1.5.5rc2

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 >

Re: [OMPI devel] Odd build breakage seen with 1.5.5rc2

t 11:28 PM, Ralph Castain <r...@open-mpi.org> 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

Re: [OMPI devel] Odd build breakage seen with 1.5.5rc2

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 Hargrove <phh

Re: [OMPI devel] Odd build breakage seen with 1.5.5rc2

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

Re: [OMPI devel] 1.5 supported systems

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

Re: [OMPI devel] Open MPI nightly tarballs suspended / 1.5.5rc3

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

Re: [OMPI devel] === CREATE FAILURE (trunk) ===

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

Re: [OMPI devel] === CREATE FAILURE (trunk) ===

anything missing. will take > another look... > > On Jul 31, 2012, at 9:04 PM, Paul Hargrove <phhargr...@lbl.gov> 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 tarb

Re: [OMPI devel] r27078 and OMPI build

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 >

Re: [OMPI devel] r27078 and OMPI build

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 24,

[OMPI devel] VT vs Oracle compilers in trunk

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

Re: [OMPI devel] r27078 and OMPI build

pletion_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 <phhargr...@lbl.gov> wrote: > OK, I have a vanilla

Re: [OMPI devel] r27078 and OMPI build

problem. > > 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 <phhargr...@lbl.gov> wrote: > > I *can* reproduce the problem

[OMPI devel] 1.6.2rc2 VT build failure [with patch]

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

Re: [OMPI devel] 1.6.2rc2 VT build failure [with patch]

/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 <phhargr...@lbl.gov> 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 te

[OMPI devel] 1.6.2rc2 VT/OMP build failure with PGI 8.0-6

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

[OMPI devel] 1.6.2rc2: opal_path_nfs failure for "bind" mount

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

Re: [OMPI devel] 1.6.2rc2 VT/OMP build failure with PGI 8.0-6

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 <phhargr...@lbl.gov> wrote: > While newer PGI compilers don't co

Re: [OMPI devel] 1.6.2rc2: opal_path_nfs failure for "bind" mount

] On Tue, Sep 11, 2012 at 12:40 PM, Ralph Castain <r...@open-mpi.org> 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, a

Re: [OMPI devel] 1.6.2rc2 VT/OMP build failure with PGI 8.0-6

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 <bert.wes...@googlemail.com>wrote: > Hi, > > On Tue, Sep 11, 2012 at 9:38 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Following-up as promised

[OMPI devel] 1.6.2rc2 build failure w/ icc on IA64

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.

Re: [OMPI devel] 1.6.2rc2: opal_path_nfs failure for "bind" mount

possible if one gets ambitious. -Paul On Wed, Sep 12, 2012 at 7:38 AM, Jeff Squyres <jsquy...@cisco.com> 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 P

<    1   2   3   4   5   6   7   8   9   >