Re: [OMPI devel] Announcing Open MPI v5.0.0rc2

[Marco Atzeri via devel]

On 10.01.2022 06:50, Marco Atzeri wrote:

On 09.01.2022 15:54, Ralph Castain via devel wrote:

Hi Marco

Try the patch here (for the prrte 3rd-party subdirectory): 
https://github.com/openpmix/prrte/pull/1173



Ralph



Thanks Ralph,

I will do on the next build
as I need still to test the current build.



The test are not satisfactory

I have only one test fail
  FAIL: dlopen_test.exe

that I supect is due to a wrong name on test

but a simple run fails

$ mpirun -n 4 ./hello_c.exe
[116] 
/pub/devel/openmpi/v5.0/openmpi-5.0.0-0.1.x86_64/src/openmpi-5.0.0rc2/3rd-party/openpmix/src/mca/ptl/base/ptl_base_listener.c:498 
bind() failed for socket 13 storage size 16: Cannot assign requested address
Hello, world, I am 0 of 1, (Open MPI v5.0.0rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 5.0.0rc2, repo rev: 
v5.0.0rc2, Oct 18, 2021, 125)

--
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):

  PML add procs failed
  --> Returned "Not found" (-13) instead of "Success" (0)
--
[LAPTOP-82F08ILC:0] *** An error occurred in MPI_Init
[LAPTOP-82F08ILC:0] *** reported by process [36547002369,1]
[LAPTOP-82F08ILC:0] *** on a NULL communicator
[LAPTOP-82F08ILC:0] *** Unknown error
[LAPTOP-82F08ILC:0] *** MPI_ERRORS_ARE_FATAL (processes in this 
communicator will now abort,
[LAPTOP-82F08ILC:0] ***and MPI will try to terminate your MPI 
job as well)

--

Suggestion for what to look for ?

Regards
Marco

Re: [OMPI devel] Announcing Open MPI v5.0.0rc2

[Marco Atzeri via devel]

On 09.01.2022 15:54, Ralph Castain via devel wrote:

Hi Marco

Try the patch here (for the prrte 3rd-party subdirectory): 
https://github.com/openpmix/prrte/pull/1173


Ralph



Thanks Ralph,

I will do on the next build
as I need still to test the current build.


To complete the build I also needed the attached:


5.0.0rc2-amend-DEF.patch
to correct a missing def in OPAL

CYGWIN-undefined.patch
to pass "-no-undefined" to pmix and romio to allow shared lib

CYGWIN-interface-workaround.patch
temporary workaround to avoid the "interface" collision with 
Windows headers

I will look to provide a better solution for this point.

Regards
Marco
--- origsrc/openmpi-5.0.0rc2/opal/util/minmax.h 2021-10-18 17:27:42.0 
+0200
+++ src/openmpi-5.0.0rc2/opal/util/minmax.h 2022-01-09 12:46:07.148969800 
+0100
@@ -40,7 +40,7 @@ OPAL_DEFINE_MINMAX(float, float)
 OPAL_DEFINE_MINMAX(double, double)
 OPAL_DEFINE_MINMAX(void *, ptr)
 
-#if OPAL_C_HAVE__GENERIC
+#ifdef OPAL_C_HAVE__GENERIC
 #define opal_min(a, b) \
 (_Generic((a) + (b),\
  int8_t: opal_min_8,\
--- 
origsrc/openmpi-5.0.0rc2/3rd-party/prrte/src/mca/oob/tcp/oob_tcp_connection.c   
2021-10-18 17:28:05.0 +0200
+++ src/openmpi-5.0.0rc2/3rd-party/prrte/src/mca/oob/tcp/oob_tcp_connection.c   
2022-01-09 11:13:29.687212300 +0100
@@ -160,6 +160,9 @@ void prte_oob_tcp_peer_try_connect(int f
 prte_oob_tcp_peer_t *peer;
 prte_oob_tcp_addr_t *addr;
 bool connected = false;
+#if defined interface
+#  undef interface
+#endif
 prte_if_t *interface;
 char *host;
 
--- origsrc/openmpi-5.0.0rc2/opal/mca/btl/tcp/btl_tcp_proc.c2021-10-18 
17:27:42.0 +0200
+++ src/openmpi-5.0.0rc2/opal/mca/btl/tcp/btl_tcp_proc.c2022-01-09 
12:48:27.075225600 +0100
@@ -160,6 +160,9 @@ static int mca_btl_tcp_proc_create_inter
fields needed in the proc version */
 for (i = 0; i < btl_proc->proc_addr_count; i++) {
 /* Construct opal_if_t objects for the remote interfaces */
+#ifdef interface
+#  undef interface
+#endif
 opal_if_t *interface = OBJ_NEW(opal_if_t);
 if (NULL == interface) {
 rc = OPAL_ERR_OUT_OF_RESOURCE;
--- origsrc/openmpi-5.0.0rc2/3rd-party/openpmix/configure.ac2021-10-18 
17:28:09.0 +0200
+++ src/openmpi-5.0.0rc2/3rd-party/openpmix/configure.ac2022-01-09 
04:51:14.271907200 +0100
@@ -337,6 +337,23 @@ AC_ARG_ENABLE(werror,
 ])
 
 
+# no-undefined needed on some platform for shared lib
+
+
+AC_MSG_CHECKING([if libtool needs -no-undefined flag to build shared 
libraries])
+case "`uname`" in
+  CYGWIN*|MINGW*|AIX*)
+## Add in the -no-undefined flag to LDFLAGS for libtool.
+AC_MSG_RESULT([yes])
+LDFLAGS="$LDFLAGS -no-undefined"
+;;
+  *)
+## Don't add in anything.
+AC_MSG_RESULT([no])
+;;
+esac
+
+
 # Version information
 
 
--- origsrc/openmpi-5.0.0rc2/3rd-party/romio341/configure.ac2021-10-18 
17:27:42.0 +0200
+++ src/openmpi-5.0.0rc2/3rd-party/romio341/configure.ac2022-01-09 
04:58:32.150499100 +0100
@@ -1784,6 +1784,19 @@ AM_PROG_LIBTOOL
 # support gcov test coverage information
 PAC_ENABLE_COVERAGE
 
+AC_MSG_CHECKING([if libtool needs -no-undefined flag to build shared 
libraries])
+case "`uname`" in
+  CYGWIN*|MINGW*|AIX*)
+## Add in the -no-undefined flag to LDFLAGS for libtool.
+AC_MSG_RESULT([yes])
+LDFLAGS="$LDFLAGS -no-undefined"
+;;
+  *)
+## Don't add in anything.
+AC_MSG_RESULT([no])
+;;
+esac
+
 AC_MSG_NOTICE([setting CC to $CC])
 AC_MSG_NOTICE([setting F77 to $F77])
 AC_MSG_NOTICE([setting TEST_CC to $TEST_CC])
--- origsrc/openmpi-5.0.0rc2/3rd-party/romio341/mpl/configure.ac
2021-10-18 17:27:42.0 +0200
+++ src/openmpi-5.0.0rc2/3rd-party/romio341/mpl/configure.ac2022-01-09 
05:01:27.462723200 +0100
@@ -1077,6 +1077,19 @@ CFLAGS=""
 AX_GCC_FUNC_ATTRIBUTE(fallthrough)
 PAC_POP_ALL_FLAGS
 
+AC_MSG_CHECKING([if libtool needs -no-undefined flag to build shared 
libraries])
+case "`uname`" in
+  CYGWIN*|MINGW*|AIX*)
+## Add in the -no-undefined flag to LDFLAGS for libtool.
+AC_MSG_RESULT([yes])
+LDFLAGS="$LDFLAGS -no-undefined"
+;;
+  *)
+## Don't add in anything.
+AC_MSG_RESULT([no])
+;;
+esac
+
 dnl Final output
 AC_CONFIG_FILES([Makefile localdefs include/mpl_timer.h])
 AC_OUTPUT

Re: [OMPI devel] Announcing Open MPI v5.0.0rc2

[Marco Atzeri via devel]

On 01.01.2022 20:07, Barrett, Brian wrote:

Marco -

There are some patches that haven't made it to the 5.0 branch to make this 
behavior better.  I didn't get a chance to back port them before the holiday 
break, but they will be in the next RC.  That said, the issue below is a 
warning, not an error, so you should still end up with a build that works (with 
an included PMIx).  The issue is that png-config can't be found, so we have 
trouble guessing what libraries are dependencies of PMIx, which is a potential 
problem in complicated builds with static libraries.

Brian



Thanks Brian,

the build error was in reality in setting for threads.

I was using up to v4.1

  --with-threads=posix

that currently is not accepted anymore but no error is reported,
causing a different setting that does not work in CYGWIN.
Removing the configuration seems to work


I have however found a logic error in prrte that
probably need a verification of all the HAVE_*_H
between configuration and code


/pub/devel/openmpi/v5.0/openmpi-5.0.0-0.1.x86_64/src/openmpi-5.0.0rc2/3rd-party/prrte/src/mca/odls/default/odls_default_module.c:114:14: 
fatal error: sys/ptrace.h: No such file or directory

  114 | #include 
  |  ^~

caused by

$ grep -rH HAVE_SYS_PTRACE_H .
./3rd-party/prrte/config.log:| #define HAVE_SYS_PTRACE_H 0
./3rd-party/prrte/config.log:| #define HAVE_SYS_PTRACE_H 0
./3rd-party/prrte/config.log:#define HAVE_SYS_PTRACE_H 0
./3rd-party/prrte/config.status:D["HAVE_SYS_PTRACE_H"]=" 0"
./3rd-party/prrte/src/include/prte_config.h:#define HAVE_SYS_PTRACE_H 0

while the code in
3rd-party/prrte/src/mca/odls/default/odls_default_module.c
has

#ifdef HAVE_SYS_PTRACE_H
#include 
#endif


currently I am stacked at

0rc2/3rd-party/prrte/src/mca/oob/tcp/oob_tcp_connection.c:61:
/pub/devel/openmpi/v5.0/openmpi-5.0.0-0.1.x86_64/src/openmpi-5.0.0rc2/3rd-party/prrte/s
rc/mca/oob/tcp/oob_tcp_connection.c: In function 
‘prte_oob_tcp_peer_try_connect’:
/pub/devel/openmpi/v5.0/openmpi-5.0.0-0.1.x86_64/src/openmpi-5.0.0rc2/3rd-party/prrte/src/mca/oob/tcp/oob_tcp_connection.c:163:16: 
error: expected identifier or ‘(’ before ‘struct’

  163 | prte_if_t *interface;
  |^
/pub/devel/openmpi/v5.0/openmpi-5.0.0-0.1.x86_64/src/openmpi-5.0.0rc2/3rd-party/prrte/src/mca/oob/tcp/oob_tcp_connection.c:180:19: 
error: expected ‘{’ before ‘=’ token

  180 | interface = PRTE_NEW(prte_if_t);
  |   ^


not sure if it is caused by new GCC 11 requirement or from wrong headers
being pulled in.

Has anyone built with GCC 11 ?

Regards
Marco

Re: [OMPI devel] Announcing Open MPI v5.0.0rc2

[Marco Atzeri via devel]

On 18.10.2021 20:39, Austen W Lauria via devel wrote:
The second release candidate for the Open MPI v5.0.0 release is posted 
at: https://www.open-mpi.org/software/ompi/v5.0/ 




Question:
there is a easy way to configure and build the 3rd party included
in the package source for a simple build ?


configure: = done with 3rd-party/openpmix configure =
checking for pmix.h... no
configure: Looking for pc file for pmix
Package pmix was not found in the pkg-config search path.
Perhaps you should add the directory containing `pmix.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pmix', required by 'virtual:world', not found
configure: WARNING: Could not find viable pmix.pc


Regards
Marco

Cygwin package maintainer

Re: [OMPI devel] Announcing Open MPI v4.0.4rc2

[Marco Atzeri via devel]

On 06.06.2020 10:37, Ralph Castain via devel wrote:
I would have hoped that the added protections we put into PMIx would 
have resolved ds12 as well as ds21, but it is possible those changes 
didn't get into OMPI v4.0.x. Regardless, I think you should be just fine 
using the gds/hash component for cygwin. I would suggest simply 
"locking" that param into the PMIx default param file.






PMIX_MCA_gds=hash


I will set it as default plu giving advice during release

Regards
Marco

Re: [OMPI devel] Announcing Open MPI v4.0.4rc2

[Marco Atzeri via devel]

On 05.06.2020 22:29, Marco Atzeri wrote:

On 01.06.2020 20:26, Geoffrey Paulsen via devel wrote:
Open MPI v4.0.4rc2 is now available for download and test at: 
sso_last: https://www.open-mpi.org/software/ompi/v4.0/




It builds on Cygwin64 bit, and this time it runs,
but the PMIX is throwing some errors:

$ mpirun  -n 4 ./hello_c.exe
[LAPTOP-82F08ILC:02866] PMIX ERROR: INIT in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 138
[LAPTOP-82F08ILC:02866] PMIX ERROR: SUCCESS in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/common/dstore/dstore_base.c 
at line 2450
[LAPTOP-82F08ILC:02867] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02868] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02869] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02870] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
Hello, world, I am 2 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 3 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 0 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 1 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)

[LAPTOP-82F08ILC:02866] [[19692,0],0] unable to open debugger attach fifo


the second is a bit funny "PMIX ERROR: SUCCESS "

In the past on 3.1.5
https://www.mail-archive.com/devel@lists.open-mpi.org//msg21004.html
the workaround "gds = ^ds21" was used but now it seems ds12 is having 
problems




taking the hint from
https://github.com/open-mpi/ompi/issues/7516

PMIX_MCA_gds=hash

 $ mpirun  -n 4 ./hello_c.exe
Hello, world, I am 0 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 1 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 2 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 3 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)

[LAPTOP-82F08ILC:02913] [[19647,0],0] unable to open debugger attach fifo

Re: [OMPI devel] Announcing Open MPI v4.0.4rc2

[Marco Atzeri via devel]

On 01.06.2020 20:26, Geoffrey Paulsen via devel wrote:
Open MPI v4.0.4rc2 is now available for download and test at: sso_last: 
https://www.open-mpi.org/software/ompi/v4.0/




It builds on Cygwin64 bit, and this time it runs,
but the PMIX is throwing some errors:

$ mpirun  -n 4 ./hello_c.exe
[LAPTOP-82F08ILC:02866] PMIX ERROR: INIT in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 138
[LAPTOP-82F08ILC:02866] PMIX ERROR: SUCCESS in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/common/dstore/dstore_base.c 
at line 2450
[LAPTOP-82F08ILC:02867] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02868] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02869] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
[LAPTOP-82F08ILC:02870] PMIX ERROR: ERROR in file 
/pub/devel/openmpi/v4.0/openmpi-4.0.4-0.2.x86_64/src/openmpi-4.0.4rc2/opal/mca/pmix/pmix3x/pmix/src/mca/gds/ds12/gds_ds12_lock_pthread.c 
at line 168
Hello, world, I am 2 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 3 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 0 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)
Hello, world, I am 1 of 4, (Open MPI v4.0.4rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 4.0.4rc2, repo rev: 
v4.0.4rc2, May 29, 2020, 125)

[LAPTOP-82F08ILC:02866] [[19692,0],0] unable to open debugger attach fifo


the second is a bit funny "PMIX ERROR: SUCCESS "

In the past on 3.1.5
https://www.mail-archive.com/devel@lists.open-mpi.org//msg21004.html
the workaround "gds = ^ds21" was used but now it seems ds12 is having 
problems




---
Geoffrey Paulsen
Software Engineer, IBM Spectrum MPI
Email: gpaul...@us.ibm.com



Regards
Marco

Re: [OMPI devel] Please test Open MPI v4.0.4rc1

[Marco Atzeri via devel]

Am 09.05.2020 um 17:18 schrieb Howard Pritchard via devel:
Open MPI v4.0.4rc1 has been posted to 
https://www.open-mpi.org/software/ompi/v4.0/


4.0.4 -- May, 2020

---

- Fix an ABI compatibility issue with the Fortran 2008 bindings.

Thanks to Alastair McKinstry for reporting.

- Fix an issue with rpath of /usr/lib64 when building OMPI on

systems with Lustre.Thanks to David Shrader for reporting.

- Fix a memory leak occurring with certain MPI RMA operations.

- Fix an issue with ORTE's mapping of MPI processes to resources.

Thanks to Alex Margolin for reporting and providing a fix.

- Correct a problem with incorrect error codes being returned

by OMPI MPI_T functions.

- Fix an issue with debugger tools not being able to attach

to mpirun more than once.Thanks to Gregory Lee for reporting.

- Fix an issue with the Fortran compiler wrappers when using

NAG compilers.Thanks to Peter Brady for reporting.

- Fix an issue with the ORTE ssh based process launcher at scale.

Thanks to Benjamín Hernández for reporting.

- Address an issue when using shared MPI I/O operations.OMPIO will

now successfully return from the file open statement but will

raise an error if the file system does not supported shared I/O

operations.Thanks to Romain Hild for reporting.

- Fix an issue with MPI_WIN_DETACH.Thanks to Thomas Naughton for reporting.


Note this release addresses an ABI compatibility issue for the Fortran 
2008 bindings.


It will not be backward compatible with releases 4.0.0 through 4.0.3 for 
applications making use of the Fortran 2008 bindings.




build on cygwin is fine but testing simple application stucks

orterun -v -n 4 ./hello_c.exe

with no output at all. Suggestion for debugging ?
This is the first 4.0.x that I tested on cygwin.


Additional question, for what I see there is no API bump in any
shared lib versus 3.1.x series. Both produces the same dll names:

$ find . -name "*.dll"
./ompi/.libs/cygmpi-40.dll
./ompi/debuggers/.libs/cygompi_dbg_msgq.dll
./ompi/mpi/fortran/mpif-h/.libs/cygmpi_mpifh-40.dll
./ompi/mpi/fortran/use-mpi-f08/.libs/cygmpi_usempif08-40.dll
./ompi/mpi/fortran/use-mpi-ignore-tkr/.libs/cygmpi_usempi_ignore_tkr-40.dll
./opal/.libs/cygopen-pal-40.dll
./orte/.libs/cygopen-rte-40.dll

Is it correct ?

Regards
Marco

Re: [OMPI devel] 3.1.6rc2: Cygwin fifo warning

[Marco Atzeri via devel]

It seems a wrong count or a lost race, it is checking too late and the 
file and the /tmp/ompi.LAPTOP-82F08ILC.197609 tree is already close and gone



  315 30730897 [main] orterun 93 close: close(21)
  310 30731207 [main] orterun 93 fhandler_base::close: closing 
'/tmp/ompi.LAPTOP-82F08ILC.197609' handle 0x4FC

  321 30731528 [main] orterun 93 close: 0 = close(21)
  711 30820954 [main] orterun 93 close: close(20)
  543 30822098 [] orterun 93 fhandler_base::close: closing ':fifo' 
handle 0x6D8
  734 30823934 [main] orterun 93 fhandler_base::close: closing 
'/tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo' handle 0x0

  555 30824489 [main] orterun 93 close: 0 = close(20)
  573 30825062 [main] orterun 93 open: 
open(/tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo, 0x4000)
  567 30837753 [main] orterun 93 fhandler_base::open: 
(\??\D:\cygwin64T\tmp\ompi.LAPTOP-82F08ILC.197609\pid.93\0\debugger_attach_fifo, 
0x10C000)
  578 30839496 [main] orterun 93 fhandler_base::open: 0xC03A = 
NtCreateFile (0x3030303030675963, 0x8010, 
\??\D:\cygwin64T\tmp\ompi.LAPTOP-82F08ILC.197609\pid.93\0\debugger_attach_fifo, 
io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
  543 30840039 [main] orterun 93 fhandler_base::open: 0 = 
fhandler_base::open(\??\D:\cygwin64T\tmp\ompi.LAPTOP-82F08ILC.197609\pid.93\0\debugger_attach_fifo, 
0x10C000)
  564 30841145 [main] orterun 93 open: -1 = 
open(/tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo, 
0xC000), errno 2




Am 04.02.2020 um 04:17 schrieb Ralph Castain via devel:

It is the latter one it is complaining about:


  /tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo


I have no idea why it is complaining.


On Feb 3, 2020, at 2:03 PM, Marco Atzeri via devel  
wrote:

Am 03.02.2020 um 18:15 schrieb Ralph Castain via devel:

Hi Marco
mpirun isn't trying to run a debugger. It is opening a fifo pipe in case a 
debugger later wishes to attach to the running job - it is used by an 
MPIR-based debugger to let mpirun know that it is attaching. My guess is that 
the code is attempting to create the fifo in an unacceptable place under Cygwin 
- I forget the directory it is trying to use.


for what I see it write in two places

under /dev/shm  where it leave some trace
$ ls -l /dev/shm/
total 33M
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.0
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.1
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.2
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.3
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.0
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.1
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.2
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.3

and under /tmp/ompi.LAPTOP-82F08ILC.197609
as /tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo

where at the end nothing remain under /tmp

The only thing strange I see is some tentative access to /proc/elog
that does not exist in Cygwin

Re: [OMPI devel] 3.1.6rc2: Cygwin fifo warning

[Marco Atzeri via devel]

Am 03.02.2020 um 18:15 schrieb Ralph Castain via devel:

Hi Marco

mpirun isn't trying to run a debugger. It is opening a fifo pipe in case 
a debugger later wishes to attach to the running job - it is used by an 
MPIR-based debugger to let mpirun know that it is attaching. My guess is 
that the code is attempting to create the fifo in an unacceptable place 
under Cygwin - I forget the directory it is trying to use.





for what I see it write in two places

under /dev/shm  where it leave some trace
$ ls -l /dev/shm/
total 33M
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.0
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.1
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.2
-rw--- 1 Marco Kein 4.1M Feb  3 22:01 
vader_segment.LAPTOP-82F08ILC.45860001.3
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.0
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.1
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.2
-rw--- 1 Marco Kein 4.1M Feb  3 22:02 
vader_segment.LAPTOP-82F08ILC.45a60001.3


and under /tmp/ompi.LAPTOP-82F08ILC.197609
as /tmp/ompi.LAPTOP-82F08ILC.197609/pid.93/0/debugger_attach_fifo

where at the end nothing remain under /tmp

The only thing strange I see is some tentative access to /proc/elog
that does not exist in Cygwin

Re: [OMPI devel] 3.1.6rc2: Cygwin fifo warning

[Marco Atzeri via devel]

Am 02.02.2020 um 14:16 schrieb Jeff Squyres (jsquyres):

On Feb 2, 2020, at 2:17 AM, Marco Atzeri via devel  
wrote:


not a new issue as it was also in 3.1.5. what is causing the
last line of warning ?
And why a simple run should try to run a debugger ?

$ mpirun -n 4 ./hello_c
...
Hello, world, I am 3 of 4, (Open MPI v3.1.6rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.6rc2, repo rev: v3.1.6rc2, Jan 
30, 2020, 125)
[LAPTOP-82F08ILC:00154] [[18244,0],0] unable to open debugger attach fifo

this is a Cygwin 64 bit.



Can you get a stack trace for that, perchance?  The function in question to 
trap is open_fifo() in orted_submit.c.  This function can be called from 3 
different places; it would be good to know in which of the 3 it is happening.

Does Cygwin support mkfifo()?




/usr/include/sys/stat.h:int mkfifo (const char *__path, mode_t __mode );


Assuming that the message is coming from the last open_fifo call

Thread 1 "orterun" hit Breakpoint 1, open_fifo ()
at /usr/src/debug/openmpi-3.1.6rc2-1/orte/orted/orted_submit.c:2857
2857{
(gdb) bt
#0  open_fifo () at 
/usr/src/debug/openmpi-3.1.6rc2-1/orte/orted/orted_submit.c:2857
#1  0x0003783f1cf1 in attach_debugger (fd=, 
event=, arg=0x800155430)

at /usr/src/debug/openmpi-3.1.6rc2-1/orte/orted/orted_submit.c:2913
#2  0x0003784bbca0 in event_process_active_single_queue 
(activeq=0x80008b650, base=0x80008af90)
at 
/usr/src/debug/openmpi-3.1.6rc2-1/opal/mca/event/libevent2022/libevent/event.c:1370

#3  event_process_active (base=)
at 
/usr/src/debug/openmpi-3.1.6rc2-1/opal/mca/event/libevent2022/libevent/event.c:1440
#4  opal_libevent2022_event_base_loop (base=0x80008af90, 
flags=flags@entry=1)
at 
/usr/src/debug/openmpi-3.1.6rc2-1/opal/mca/event/libevent2022/libevent/event.c:1644
#5  0x0001004013de in orterun (argc=, argv=out>)

at /usr/src/debug/openmpi-3.1.6rc2-1/orte/tools/orterun/orterun.c:201
#6  0x00018004a826 in _cygwin_exit_return ()
at /usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/dcrt0.cc:1028
#7  0x000180048353 in _cygtls::call2 (this=0xce00, 
func=0x180049800 ,
arg=0x0, buf=buf@entry=0xcdf0) at 
/usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/cygtls.cc:40
#8  0x000180048404 in _cygtls::call (func=, 
arg=)

at /usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/cygtls.cc:27
#9  0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
[Thread 127164.0x54860 exited with code 0]
[LAPTOP-82F08ILC:02101] [[20459,0],0] unable to open debugger attach fifo

Re: [OMPI devel] v3.0.6rc2 and v3.1.6rc2 available for testing

[Marco Atzeri via devel]

Am 30.01.2020 um 21:39 schrieb Jeff Squyres (jsquyres) via devel:

Minor updates since rc1:

3.0.6rc2 and 3.1.6rc2:
- Fix run-time linker issues with OMPIO on newer Linux distros.

3.1.6rc2 only:
- Fix issue with zero-length blockLength in MPI_TYPE_INDEXED.

Please test:

https://www.open-mpi.org/software/ompi/v3.0/
https://www.open-mpi.org/software/ompi/v3.1/



not a new issue as it was also in 3.1.5. what is causing the
last line of warning ?
And why a simple run should try to run a debugger ?

$ mpirun -n 4 ./hello_c
...
Hello, world, I am 3 of 4, (Open MPI v3.1.6rc2, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.6rc2, repo rev: 
v3.1.6rc2, Jan 30, 2020, 125)

[LAPTOP-82F08ILC:00154] [[18244,0],0] unable to open debugger attach fifo

this is a Cygwin 64 bit.

Re: [OMPI devel] PMIX ERROR: INIT spurious message on 3.1.5

[Marco Atzeri via devel]

thanks Ralph

gds = ^ds21
works as expected

Am 31.12.2019 um 19:27 schrieb Ralph Castain via devel:

PMIx likely defaults to the ds12 component - which will work fine but a tad slower than 
ds21. It is likely something to do with the way cygwin handles memory locks. You can 
avoid the error message by simply adding "gds = ^ds21" to your default MCA 
param file (the pmix one - should be named pmix-mca-params.conf).

Artem - any advice here?



On Dec 25, 2019, at 9:56 AM, Marco Atzeri via devel  
wrote:

I have no multinode around for testing

I will need to setup one for testing after the holidays

Am 24.12.2019 um 23:27 schrieb Jeff Squyres (jsquyres):

That actually looks like a legit error -- it's failing to initialize a shared 
mutex.
I'm not sure what the consequence is of this failure, though, since the job 
seemed to run ok.
Are you able to run multi-node jobs ok?

On Dec 22, 2019, at 1:20 AM, Marco Atzeri via devel  
wrote:

Hi Developers,

Cygwin 64bit, openmpi-3.1.5-1
testing the cygwin package before releasing it
I see a never seen before spurious error messages that do not seem
about error at all:

$ mpirun -n 4 ./hello_c.exe
[LAPTOP-82F08ILC:02395] PMIX ERROR: INIT in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/gds/ds21/gds_ds21_lock_pthread.c
 at line 188
[LAPTOP-82F08ILC:02395] PMIX ERROR: SUCCESS in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/common/dstore/dstore_base.c
 at line 2432
Hello, world, I am 0 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 1 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 2 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 3 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
[LAPTOP-82F08ILC:02395] [[20101,0],0] unable to open debugger attach fifo

There is a know workaround ?
I have not found anything on the issue list.

Regards
MArcp

Re: [OMPI devel] PMIX ERROR: INIT spurious message on 3.1.5

[Marco Atzeri via devel]

I have no multinode around for testing

I will need to setup one for testing after the holidays

Am 24.12.2019 um 23:27 schrieb Jeff Squyres (jsquyres):

That actually looks like a legit error -- it's failing to initialize a shared 
mutex.

I'm not sure what the consequence is of this failure, though, since the job 
seemed to run ok.

Are you able to run multi-node jobs ok?



On Dec 22, 2019, at 1:20 AM, Marco Atzeri via devel  
wrote:

Hi Developers,

Cygwin 64bit, openmpi-3.1.5-1
testing the cygwin package before releasing it
I see a never seen before spurious error messages that do not seem
about error at all:

$ mpirun -n 4 ./hello_c.exe
[LAPTOP-82F08ILC:02395] PMIX ERROR: INIT in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/gds/ds21/gds_ds21_lock_pthread.c
 at line 188
[LAPTOP-82F08ILC:02395] PMIX ERROR: SUCCESS in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/common/dstore/dstore_base.c
 at line 2432
Hello, world, I am 0 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 1 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 2 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
Hello, world, I am 3 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 15, 
2019, 116)
[LAPTOP-82F08ILC:02395] [[20101,0],0] unable to open debugger attach fifo

There is a know workaround ?
I have not found anything on the issue list.

Regards
MArcp

[OMPI devel] PMIX ERROR: INIT spurious message on 3.1.5

[Marco Atzeri via devel]

Hi Developers,

Cygwin 64bit, openmpi-3.1.5-1
testing the cygwin package before releasing it
I see a never seen before spurious error messages that do not seem
about error at all:

 $ mpirun -n 4 ./hello_c.exe
[LAPTOP-82F08ILC:02395] PMIX ERROR: INIT in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/gds/ds21/gds_ds21_lock_pthread.c 
at line 188
[LAPTOP-82F08ILC:02395] PMIX ERROR: SUCCESS in file 
/cygdrive/d/cyg_pub/devel/openmpi/v3.1/openmpi-3.1.5-1.x86_64/src/openmpi-3.1.5/opal/mca/pmix/pmix2x/pmix/src/mca/common/dstore/dstore_base.c 
at line 2432
Hello, world, I am 0 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 
15, 2019, 116)
Hello, world, I am 1 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 
15, 2019, 116)
Hello, world, I am 2 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 
15, 2019, 116)
Hello, world, I am 3 of 4, (Open MPI v3.1.5, package: Open MPI 
Marco@LAPTOP-82F08ILC Distribution, ident: 3.1.5, repo rev: v3.1.5, Nov 
15, 2019, 116)

[LAPTOP-82F08ILC:02395] [[20101,0],0] unable to open debugger attach fifo

There is a know workaround ?
I have not found anything on the issue list.

Regards
MArcp

Re: [OMPI devel] Openmpi configure: Could not determine the fortran compiler flag

[Marco Atzeri]

Am 21.10.2018 um 09:56 schrieb Santiago Serebrinsky:

Hi all,

I am using Msys2 from PortableApps under Win10. More precisely,

|$ uname -a MSYS_NT-10.0-WOW Galapagos 2.11.1(0.329/5/3) 2018-09-10 13:25 
i686 Msys |


I mean to install openmpi. Since I found no pre-built package (I would 
love to have it!), I downloaded openmpi-3.1.2. When I


|./configure --prefix=$HOME/usr/local |

after many config detections, I get

|checking for Fortran compiler module include flag... configure: WARNING: 
*** Could not determine the fortran compiler flag to indicate where 
modules reside configure: error: *** Cannot continue|




what fortran compiler do you have ?

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

[Marco Atzeri]

Am 02.10.2018 um 07:47 schrieb Brice Goglin:

Le 02/10/2018 à 00:28, Marco Atzeri a écrit :

Am 01.10.2018 um 19:57 schrieb Brice Goglin:

Le 01/10/2018 à 19:22, Marco Atzeri a écrit :




Your own machine doesn't matter. None is these tests look at your CPU or
topology. *All* of them on all x86 machines.
CPUID are emulated by reading files, nothing is read from your local
machine topology. There's just something wrong here that prevents these
emulating CPUID files from being read. "lstopo -i ..." will tell you.


$ 
/pub/devel/hwloc/hwloc-2.0.2-1.x86_64/build/utils/lstopo/lstopo-no-graphics.exe 
 -i 
/pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/tests/hwloc/x86/AMD-15h-Bulldozer-4xOpteron-6272/ 
 --if cpuid --of xml -

Ignoring dumped cpuid directory.



It works instead with "--if xml"

IMHO, should be better to produce an error
instead of the local machine output with a warning,
if the input is not understandable


The input is understandable here, but there's a cygwin-related bug 
somewhere when we actually try to use it.


--if xml makes no sense here since you're not giving any XML as input.


of course with "--if xml" I used the XML file *.output.as input file.

The error message comes from hwloc_x86_check_cpuiddump_input() failing 
in hwloc/topology-x86.c.
That function always prints an error message before returning an error, 
except when opendir() fails on the given directory.
The directory was passed by lstopo to the core using environment 
variable HWLOC_CPUID_PATH.


Anyway, I have no way to debug this for now so you're stuck with not 
running make check in that directory :/


Brice



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

[Marco Atzeri]

Am 01.10.2018 um 19:57 schrieb Brice Goglin:

Le 01/10/2018 à 19:22, Marco Atzeri a écrit :




Your own machine doesn't matter. None is these tests look at your CPU or
topology. *All* of them on all x86 machines.
CPUID are emulated by reading files, nothing is read from your local
machine topology. There's just something wrong here that prevents these
emulating CPUID files from being read. "lstopo -i ..." will tell you.


$ 
/pub/devel/hwloc/hwloc-2.0.2-1.x86_64/build/utils/lstopo/lstopo-no-graphics.exe 
 -i 
/pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/tests/hwloc/x86/AMD-15h-Bulldozer-4xOpteron-6272/ 
 --if cpuid --of xml -

Ignoring dumped cpuid directory.



It works instead with "--if xml"

IMHO, should be better to produce an error
instead of the local machine output with a warning,
if the input is not understandable



Brice


Thanks
Marco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

[Marco Atzeri]

Am 30.09.2018 um 20:11 schrieb Samuel Thibault:

Marco Atzeri, le dim. 30 sept. 2018 20:02:59 +0200, a ecrit:

also adding a HWLOC_DECLSPEC on the first case distances.c:347
does not solve the issue as the two declaration are not the same.

Suggestion ?


Perhaps use hwloc_uint64_t instead of uint64_t in hwloc/distances.c?

Samuel


Thanks Samuel,
it was that, in more than one place.

The attached patch allowed the compilation on cygwin64 bit.

The only remaining warnings are minor one

##
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/topology-windows.c: 
In function ‘hwloc_look_windows’:
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/topology-windows.c:814:28: 
warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but 
argument 4 has type ‘ULONG_PTR {aka long long unsigned int}’ [-Wformat=]
  hwloc_debug("%s#%u mask %lx\n", hwloc_obj_type_string(type), id, 
procInfo[i].ProcessorMask);
  ~~^ 
~

  %llx
###


The only tests failing are:

FAIL: test-lstopo.sh

that seems due to a mix between Cygwin and Windows

 utils/lstopo/test-lstopo.sh.log #

Machine (3665MB total) + Package L#0
  NUMANode L#0 (P#0 3665MB)
  L3 L#0 (6144KB)
L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
  PU L#0 (P#0)
  PU L#1 (P#1)
L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
  PU L#2 (P#2)
  PU L#3 (P#3)
L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
  PU L#4 (P#4)
  PU L#5 (P#5)
L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
  PU L#6 (P#6)
  PU L#7 (P#7)
OpenProcess 13220 failed 5: Zugriff verweigert



And all the :

FAIL: Intel-Skylake-2xXeon6140.output
FAIL: Intel-Broadwell-2xXeon-E5-2650Lv4.output
FAIL: Intel-Haswell-2xXeon-E5-2680v3.output
FAIL: Intel-IvyBridge-12xXeon-E5-4620v2.output
FAIL: Intel-SandyBridge-2xXeon-E5-2650.output
FAIL: Intel-Westmere-2xXeon-X5650.output
FAIL: Intel-Nehalem-2xXeon-X5550.output
FAIL: Intel-Penryn-4xXeon-X7460.output
FAIL: Intel-Core-2xXeon-E5345.output
FAIL: Intel-KnightsLanding-XeonPhi-7210.output
FAIL: Intel-KnightsCorner-XeonPhi-SE10P.output
FAIL: AMD-17h-Zen-2xEpyc-7451.output
FAIL: AMD-15h-Piledriver-4xOpteron-6348.output
FAIL: AMD-15h-Bulldozer-4xOpteron-6272.output
FAIL: AMD-K10-MagnyCours-2xOpteron-6164HE.output
FAIL: AMD-K10-Istanbul-8xOpteron-8439SE.output
FAIL: AMD-K8-SantaRosa-2xOpteron-2218.output
FAIL: AMD-K8-SledgeHammer-2xOpteron-250.output
FAIL: Zhaoxin-CentaurHauls-ZXD-4600.output
FAIL: Zhaoxin-Shanghai-KaiSheng-ZXC+-FC1081.output
###

But it is not clear to me how these tests should pass.


The Laptop has a Quad Core I5

processor   : 7
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
stepping: 10
cpu MHz : 1800.000
cache size  : 6144 KB

Regards
Marco










---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
--- origsrc/hwloc-2.0.2/hwloc/distances.c   2018-01-26 09:56:03.0 
+0100
+++ src/hwloc-2.0.2/hwloc/distances.c   2018-10-01 13:39:46.501610500 +0200
@@ -345,7 +345,7 @@ int hwloc_internal_distances_add(hwloc_t
 /* The actual function exported to the user
  */
 int hwloc_distances_add(hwloc_topology_t topology,
-   unsigned nbobjs, hwloc_obj_t *objs, uint64_t *values,
+   unsigned nbobjs, hwloc_obj_t *objs, hwloc_uint64_t 
*values,
unsigned long kind, unsigned long flags)
 {
   hwloc_obj_type_t type;
--- origsrc/hwloc-2.0.2/hwloc/pci-common.c  2018-01-26 09:56:03.0 
+0100
+++ src/hwloc-2.0.2/hwloc/pci-common.c  2018-10-01 14:00:38.336045900 +0200
@@ -16,7 +16,7 @@
 #endif
 #include 
 
-#ifdef HWLOC_WIN_SYS
+#if defined(HWLOC_WIN_SYS) && !defined(__CYGWIN__)
 #include 
 #define open _open
 #define read _read
--- origsrc/hwloc-2.0.2/hwloc/shmem.c   2018-01-26 09:56:03.0 +0100
+++ src/hwloc-2.0.2/hwloc/shmem.c   2018-10-01 13:46:55.542444700 +0200
@@ -76,7 +76,7 @@ hwloc_shmem_topology_get_length(hwloc_to
 
 int
 hwloc_shmem_topology_write(hwloc_topology_t topology,
-  int fd, uint64_t fileoffset,
+  int fd, hwloc_uint64_t fileoffset,
   void *mmap_address, size_t length,
   unsigned long flags)
 {
@@ -259,7 +259,7 @@ hwloc_shmem_topology_get_length(hwloc_to
 
 int
 hwloc_shmem_topology_write(hwloc_topology_t topology __hwloc_attribute_unused,
-  int fd __hwloc_attribute_unused, u

[hwloc-devel] hwloc_distances_add conflicting declaration

[Marco Atzeri]

Trying to build 2.0.2 on cygwin 64 bit.

  CC   diff.lo
  CC   shmem.lo
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/distances.c:347:5: 
error: conflicting types for ‘hwloc_distances_add’

 int hwloc_distances_add(hwloc_topology_t topology,
 ^~~
In file included from 
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/include/hwloc.h:2258:0,
 from 
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/distances.c:9:
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/include/hwloc/distances.h:229:20: 
note: previous declaration of ‘hwloc_distances_add’ was here

 HWLOC_DECLSPEC int hwloc_distances_add(hwloc_topology_t topology,
^~~
In file included from 
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/include/private/private.h:29:0,
 from 
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/distances.c:10:
/cygdrive/d/cyg_pub/devel/hwloc/hwloc-2.0.2-1.x86_64/src/hwloc-2.0.2/hwloc/distances.c: 
In function ‘hwloc__groups_by_distances’:


also adding a HWLOC_DECLSPEC on the first case distances.c:347
does not solve the issue as the two declaration are not the same.

Suggestion ?



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [OMPI devel] openmpi 3.1.x examples

[Marco Atzeri]

Am 16.07.2018 um 23:05 schrieb Jeff Squyres (jsquyres) via devel:

On Jul 13, 2018, at 4:35 PM, Marco Atzeri  wrote:



For one. The C++ bindings are no longer part of the standard and they are not 
built by default in v3.1x. They will be removed entirely in Open MPI v5.0.0.


Hey Marco -- you should probably join our packagers mailing list:

 https://lists.open-mpi.org/mailman/listinfo/ompi-packagers

Low volume, but intended exactly for packagers like you.  It's fairly recent; 
we realized we needed to keep in better communication with our downstream 
packagers.



noted thanks.


(+ompi-packagers to the CC)

As Nathan mentioned, we stopped building the MPI C++ bindings by default in 
Open MPI 3.0.  You can choose to build them with the configure --enable-mpi-cxx.


I was aware, as I am not building it anymore, however
probably we should exclude the C++ from default examples.

Regards
Merco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Cygwin Fortran compiler options

[Marco Atzeri]

Am 16.07.2018 um 23:06 schrieb Jeff Squyres (jsquyres) via devel:

Split the Fortran issue off into its own thread (and kept it on devel; no need 
for ompi-packagers)


On Jul 13, 2018, at 4:35 PM, Marco Atzeri  wrote:


the fortran problem is due to a compiler settings
It works with

$ mpifort -g  hello_usempi.f90  -o hello_usempi -fintrinsic-modules-path 
/usr/lib


Should we add something to configure to detect/use this flag automatically?



no, I think it is a issue of latest fortran compiler in cygwin;
I am sure it was not like that with previous version.
I also noted that also in this ways works

$ mpifort -g  hello_usempi.f90  -o hello_usempi -I /usr/lib

probably some default changed between gcc 6.3 and 7.3

Regards
Marco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] openmpi 3.1.x examples

[Marco Atzeri]

Am 13.07.2018 um 22:07 schrieb Nathan Hjelm via devel:

For one. The C++ bindings are no longer part of the standard and they are not 
built by default in v3.1x. They will be removed entirely in Open MPI v5.0.0.

Not sure why the fortran one is not building.



the fortran problem is due to a compiler settings
It works with

$ mpifort -g  hello_usempi.f90  -o hello_usempi -fintrinsic-modules-path 
/usr/lib


---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

[OMPI devel] openmpi 3.1.x examples

[Marco Atzeri]

Hi,
may be I am missing something obvious, but are the
examples still actual

  C:   hello_c.c
  C++: hello_cxx.cc
  Fortran mpif.h:  hello_mpifh.f
  Fortran use mpi: hello_usempi.f90
  Fortran use mpi_f08: hello_usempif08.f90
  Java:Hello.java
  C shmem.h:   hello_oshmem_c.c
  Fortran shmem.fh:hello_oshmemfh.f90


$ make hello_cxx
mpic++ -g  hello_cxx.cc  -o hello_cxx
hello_cxx.cc: In function ‘int main(int, char**)’:
hello_cxx.cc:25:5: error: ‘MPI’ has not been declared

$ make -i
...
mpifort -g  hello_usempi.f90  -o hello_usempi
hello_usempi.f90:14:8:

 use mpi
1
Fatal Error: Can't open module file ‘mpi.mod’ for reading at (1): No 
such file or directory


The second could be a different problem

$ ls /usr/lib/mpi.mod
/usr/lib/mpi.mod


---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] openmpi-3.1.0 cygwin patch

[Marco Atzeri]

On 6/16/2018 6:15 PM, Jeff Squyres (jsquyres) via devel wrote:

Thanks Macro.  I've filed https://github.com/open-mpi/ompi/pull/5277 here for 
master; will follow up with PR's to the release branches after that passes CI / 
is merged.



Hi Jeff,
please apply both patches

the current 3.1.0 package is built with the first one and libevent internal.
http://www.cygwin.com/ml/cygwin-announce/2018-06/msg00010.html


While both the internal and external build complete and pass the tests,
only the internal one is correctly working with examples and
osu bechmarks.

The build with external libevent frozes with no messages when trying the
examples.
For personal reason I have no much time to investigate; so it could take 
time to identify the root cause.

One possibility is that libevent package was built with gcc-6.3 and
now for openmpi I am using the gcc-7.3.

Same for 3.1.1rc1

Regards
Marco





___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] openmpi-3.1.0 cygwin patch

[Marco Atzeri]

On 5/28/2018 11:58 AM, Marco Atzeri wrote:

On 5/24/2018 11:07 AM, Marco Atzeri wrote:

On 5/23/2018 2:58 PM, Gilles Gouaillardet wrote:

Marco,

Have you tried to build Open MPI with an external (e.g. Cygwin 
provided) libevent library ?

If that works, I think that would be the preferred method.

Cheers,

Gilles


I will try.
If I remember right there was an issue in the past as
somewhere a WIN32 was defined an it was screwing the build.

Regards
Marco



I am validating a patch workaround to see if it works with both
internal and external libevent.

The build with external libevent passed all
osu-micro-benchmarks-5.4.2 MPI tests



attached patch allows build of 3.1.0 on cygwin 32 bit
and 64 bit versions, configured with

--with-libevent=external \
--disable-mca-dso \
--disable-sysv-shmem \
--enable-cxx-exceptions \
--with-threads=posix \
--without-cs-fs \
--with-mpi-param_check=always \
--enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv,patcher

the 64 bit version also use
  --enable-builtin-atomics

Tested with libevent 2.0.22-1

Regards
Marco

--- origsrc/openmpi-3.1.0/opal/mca/event/external/external.h2018-05-07 
22:42:22.0 +0200
+++ src/openmpi-3.1.0/opal/mca/event/external/external.h2018-05-25 
19:54:58.710800500 +0200
@@ -22,6 +22,10 @@
 
 #include "opal_config.h"
 
+#if defined(__CYGWIN__) && defined(WIN32)
+#undef WIN32
+#endif 
+
 #include "event.h"
 #include "event2/event.h"
 #include "event2/thread.h"
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] openmpi-3.1.0 cygwin patch

[Marco Atzeri]

On 5/24/2018 11:07 AM, Marco Atzeri wrote:

On 5/23/2018 2:58 PM, Gilles Gouaillardet wrote:

Marco,

Have you tried to build Open MPI with an external (e.g. Cygwin 
provided) libevent library ?

If that works, I think that would be the preferred method.

Cheers,

Gilles


I will try.
If I remember right there was an issue in the past as
somewhere a WIN32 was defined an it was screwing the build.

Regards
Marco



I am validating a patch workaround to see if it works with both
internal and external libevent.

The build with external libevent passed all
osu-micro-benchmarks-5.4.2 MPI tests



Regards
Marco

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] openmpi-3.1.0 cygwin patch

[Marco Atzeri]

On 5/23/2018 2:58 PM, Gilles Gouaillardet wrote:

Marco,

Have you tried to build Open MPI with an external (e.g. Cygwin provided) 
libevent library ?

If that works, I think that would be the preferred method.

Cheers,

Gilles


I will try.
If I remember right there was an issue in the past as
somewhere a WIN32 was defined an it was screwing the build.

Regards
Marco



___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

[OMPI devel] openmpi-3.1.0 cygwin patch

[Marco Atzeri]

The attached patch allows the compilation of openmpi-3.1.0
on cygwin 32 and 64 bit with gcc 7.3


It is basically the same already proposed in the past for 2.1.2

I will release the cygwin package as soon we roll out
the gcc 7.3 compiler

Regards
Marco
--- origsrc/openmpi-3.1.0/opal/mca/event/libevent2022/libevent/event.h  
2018-05-07 22:42:22.0 +0200
+++ src/openmpi-3.1.0/opal/mca/event/libevent2022/libevent/event.h  
2018-05-21 15:05:39.09000 +0200
@@ -56,7 +56,7 @@ extern "C" {
 /* For int types. */
 #include 
 
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
 #ifndef WIN32_LEAN_AND_MEAN
 #define WIN32_LEAN_AND_MEAN
 #endif
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] how to disable memory/patcher build ?

[Marco Atzeri]

On 31/10/2017 08:50, Gilles Gouaillardet wrote:

Marco,


can you please give the attached patch a try ?
so far, it compiles for me.


thanks Gilles,
it works

btw, i faced some issues (conflicting definitions between windows.h and 
netdb.h),


did you need some patches in order to solve these issues ?


attached the one I used

 
Cheers,

Gilles


Regards
Marco


--- origsrc/openmpi-2.1.2/opal/mca/event/libevent2022/libevent/event.h  
2017-05-10 17:40:49.0 +0200
+++ src/openmpi-2.1.2/opal/mca/event/libevent2022/libevent/event.h  
2017-09-28 20:15:47.546805000 +0200
@@ -56,7 +56,7 @@ extern "C" {
 /* For int types. */
 #include 
 
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
 #ifndef WIN32_LEAN_AND_MEAN
 #define WIN32_LEAN_AND_MEAN
 #endif
--- origsrc/openmpi-2.1.2/opal/mca/event/libevent2022/libevent2022.h
2017-05-10 17:41:36.0 +0200
+++ src/openmpi-2.1.2/opal/mca/event/libevent2022/libevent2022.h
2017-09-28 20:16:31.344082400 +0200
@@ -25,7 +25,7 @@
 #include 
 #endif
 
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
 #define WIN32_LEAN_AND_MEAN
 #include 
 #undef WIN32_LEAN_AND_MEAN
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] how to disable memory/patcher build ?

[Marco Atzeri]

ping ?
It is a blocking issue for any effort to move on
further cygwin release after 1.10.7

https://github.com/open-mpi/ompi/issues/4282


On 28/09/2017 21:33, Marco Atzeri wrote:

Hi,
restarting the effort to build 2.1.2 on cygwin I hit:

make[2]: Entering directory 
'/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/build/opal/mca/memory/patcher' 


   CC   memory_patcher_component.lo
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/src/openmpi-2.1.2/opal/mca/memory/patcher/memory_patcher_component.c: 
In function ‘_intercept_munmap’:
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/src/openmpi-2.1.2/opal/mca/memory/patcher/memory_patcher_component.c:98:32: 
warning: implicit declaration of function ‘syscall’ 
[-Wimplicit-function-declaration]

  #define memory_patcher_syscall syscall

I tried with configuration

  --disable-mca-dso \
  --disable-sysv-shmem \
  --enable-cxx-exceptions \
  --with-threads=posix \
  --without-cs-fs \
  --with-mpi-param_check=always \
  --enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv,patcher 



but it is not effective.

I would expect that of directories

opal/mca/memory/base
opal/mca/memory/malloc_solaris
opal/mca/memory/patcher

only base is build and the other two : patcher and malloc_solaris,
  are skipped as the conditions are not met.

Suggestion/Workaround ?

Regards
Marco


___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

[OMPI devel] how to disable memory/patcher build ?

[Marco Atzeri]

Hi,
restarting the effort to build 2.1.2 on cygwin I hit:

make[2]: Entering directory 
'/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/build/opal/mca/memory/patcher'

  CC   memory_patcher_component.lo
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/src/openmpi-2.1.2/opal/mca/memory/patcher/memory_patcher_component.c: 
In function ‘_intercept_munmap’:
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/openmpi-2.1.2-1.x86_64/src/openmpi-2.1.2/opal/mca/memory/patcher/memory_patcher_component.c:98:32: 
warning: implicit declaration of function ‘syscall’ 
[-Wimplicit-function-declaration]

 #define memory_patcher_syscall syscall

I tried with configuration

 --disable-mca-dso \
 --disable-sysv-shmem \
 --enable-cxx-exceptions \
 --with-threads=posix \
 --without-cs-fs \
 --with-mpi-param_check=always \
 --enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv,patcher

but it is not effective.

I would expect that of directories

opal/mca/memory/base
opal/mca/memory/malloc_solaris
opal/mca/memory/patcher

only base is build and the other two : patcher and malloc_solaris,
 are skipped as the conditions are not met.

Suggestion/Workaround ?

Regards
Marco

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

On 07/09/2017 16:38, Marco Atzeri wrote:

On 07/09/2017 16:29, Jeff Squyres (jsquyres) wrote:

On Sep 7, 2017, at 9:09 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:


further issue on cygwin, in addition to an easy libevent issue that I 
already patched.


Is that a patch we should:

a) submit upstream to libevent
b) patch locally in Open MPI

?


Hi Jeff,
ideally (a) as it seems that any new libevent version is causing (b).
I looked at the old patch submitted for 1.7.3 for guidance.

As soon I finish the test I will submit the new patch.



Looking in more depth, we have already libevent as
cygwin package

$ cygcheck -cd |grep event
libevent-devel  2.0.22-1
libevent2.0_5   2.0.22-1

and I see that it builds from source with no patch,
so I see two possibilities:

or there is a version mismatch as from
  libevent2022/libevent/configure.ac
it seems a patched 2.0.21-stable and not a 2.0.22
release;

or something is defining WIN32 before configuring
libevent and creating the problem with Cygwin
that requires a lot of
   #if defined(WIN32) && !defined(__CYGWIN__)



Regards
Marco

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

On 07/09/2017 16:29, Jeff Squyres (jsquyres) wrote:

On Sep 7, 2017, at 9:09 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:





Yes, "patcher" replaces the old malloc hooks.

I don't think we looked at how patcher would function on Cygwin at all -- it 
probably isn't relevant on Windows, because it's only necessary for OS-bypass 
networks (which I'm pretty sure Open MPI doesn't support on Windows).




It seems the configure portion of patcher is not correctly
managing the failures.
All tests in the last portion of patcher/configure.m4 failed,
but the component is selected.

extracted from config.log
-
configure:122286: result: malloc_solaris, patcher
configure:5683: --- MCA component memory:patcher (m4 configuration 
macro, priori

ty 41)
configure:122374: checking for MCA component memory:patcher compile mode
configure:122377: result: static
configure:122388: checking for __curbrk
configure:122388: gcc -o conftest.exe -DNDEBUG -ggdb -O2 -pipe 
-Wimplicit-functi

[cut]
truncated to fit: R_X86_64_PC32 against undefined symbol `__curbrk'
collect2: error: ld returned 1 exit status
configure:122388: $? = 1
configure: failed program was:
configure:122388: result: no
configure:122401: checking linux/mman.h usability
[cut]
conftest.c:690:24: fatal error: linux/mman.h: No such file or directory
 #include 
^
compilation terminated.
configure:122401: $? = 1
configure: failed program was:
configure:122401: result: no
configure:122401: checking linux/mman.h presence
[cut]
conftest.c:657:24: fatal error: linux/mman.h: No such file or directory
 #include 
^
compilation terminated.
configure:122401: $? = 1
configure: failed program was:
configure:122401: result: no
configure:122401: checking for linux/mman.h
configure:122401: result: no
[cut]
configure:122452: checking for __syscall
configure:122452: gcc -o conftest.exe -DNDEBUG -ggdb -O2 -pipe [cut[]
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`__syscall'

collect2: error: ld returned 1 exit status
configure:122452: $? = 1
configure: failed program was:
configure:122452: result: no
configure:122496: checking if MCA component memory:patcher can compile
configure:122498: result: yes


malloc_solaris/configure.m4 is working properly.

configure:5683: --- MCA component memory:malloc_solaris (m4 
configuration macro, priority 0)
configure:123083: checking for MCA component memory:malloc_solaris 
compile mode

configure:123086: result: static
configure:123133: checking for Solaris
configure:123306: result: no
configure:123839: checking if MCA component memory:malloc_solaris can 
compile

configure:123841: result: no

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

On 07/09/2017 16:29, Jeff Squyres (jsquyres) wrote:

On Sep 7, 2017, at 9:09 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:


further issue on cygwin, in addition to an easy libevent issue that I already 
patched.


Is that a patch we should:

a) submit upstream to libevent
b) patch locally in Open MPI

?


Hi Jeff,
ideally (a) as it seems that any new libevent version is causing (b).
I looked at the old patch submitted for 1.7.3 for guidance.

As soon I finish the test I will submit the new patch.




it seems "opal/mca/memory/patcher" is new compared to 1.10.x and the 
compilation fail

[cut]

can someone guide me on the scope of new component in
which case is supposed to be included ?
I supposed it should be excluded like the others linux
and malloc_solaris directory


Yes, "patcher" replaces the old malloc hooks.

I don't think we looked at how patcher would function on Cygwin at all -- it 
probably isn't relevant on Windows, because it's only necessary for OS-bypass 
networks (which I'm pretty sure Open MPI doesn't support on Windows).



Suggestion on how to exclude it ?

Regards
Marco
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

30/08/2017 22:48, Howard Pritchard wrote:

Hi Folks,

Open MPI 2.1.2rc3 tarballs are available for testing at the usual place:

https://www.open-mpi.org/software/ompi/v2.1/



further issue on cygwin, in addition to an easy libevent issue that I 
already patched.


it seems "opal/mca/memory/patcher" is new compared to 1.10.x and the 
compilation fail



/cygdrive/e/cyg_pub/devel/openmpi/v2.1/prova/openmpi-2.1.2-0.3.x86_64/src/openmpi-2.1.2rc3/opal/mca/memory/patcher/memory_patcher_component.c:98:32: 
warning: implicit declaration of function ‘syscall’ 
[-Wimplicit-function-declaration]

 #define memory_patcher_syscall syscall
^
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/prova/openmpi-2.1.2-0.3.x86_64/src/openmpi-2.1.2rc3/opal/mca/memory/patcher/memory_patcher_component.c:165:18: 
note: in expansion of macro ‘memory_patcher_syscall’

 result = memory_patcher_syscall(SYS_munmap, start, length);
  ^~
/cygdrive/e/cyg_pub/devel/openmpi/v2.1/prova/openmpi-2.1.2-0.3.x86_64/src/openmpi-2.1.2rc3/opal/mca/memory/patcher/memory_patcher_component.c:165:41: 
error: ‘SYS_munmap’ undeclared (first use in this function)

 result = memory_patcher_syscall(SYS_munmap, start, length);


can someone guide me on the scope of new component in
which case is supposed to be included ?
I supposed it should be excluded like the others linux
and malloc_solaris directory

Regards
Marco
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

On 05/09/2017 17:35, Jeff Squyres (jsquyres) wrote:

Marco -

Remind me: are you running autogen.pl for a Cygwin-specific reason?

I'm unable to replicate your issue:

- I downloaded the 2.1.2rc3 tarball
- I ran autogen.pl in the tarball
- I built the tarball (tried both normal build and a VPATH build)

I can confirm, too, that config/opal_get_version.sh is in the tarball, too.

Can you provide a little more information?



I noticed the removal of autogen.sh but not the replacement with
autogen.pl so I was using the standard autoreconf.

I will test and will let you know, unfortunately
due to computer issue I am behind making test on the more
complex software like openmpi.

Regards
Marco

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 2.1.2rc3 available for testing

[Marco Atzeri]

On 30/08/2017 22:48, Howard Pritchard wrote:

Hi Folks,

Open MPI 2.1.2rc3 tarballs are available for testing at the usual place:

https://www.open-mpi.org/software/ompi/v2.1/

Fixes since rc2:

Issue #4122: CMA compilation error in SM BTL.    Thanks to Paul Hargrove 
for catching this.
Issue #4034: NAG Fortran compiler -rpath configuration error.  Thanks to 
Neil Carlson for

reporting.

Also, removed support for big endian PPC and XL compilers older than 13.1.

Thanks,

Jeff and Howard




already seen on 2.1.1

autoreconf-2.69: running: aclocal --force -I config
sh: config/opal_get_version.sh: No such file or directory
sh: config/opal_get_version.sh: No such file or directory


I thought there was a file name mismatch

$ file opal_get*
opal_get_version.m4:   M4 macro processor script, ASCII text
opal_get_version.m4sh: ASCII text

but it is not.
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] query on atomic operations

[Marco Atzeri]

On 01/04/2016 17:51, Nathan Hjelm wrote:


This is done to provide the functionality when the compiler doesn't
support inline asm. I do not know how testing is done with the atomics
in  opal/asm/base atomics so its possible some of them are incorrect.

-Nathan



I should say that the testing is inaccurate.

I finally looked at why opal_atomic_cmpset_32 was segfaulting
on cygwin 64 bit tests and the reason is very simple,
the calling convention on AMD64 for windows is different
than on Linux.

https://msdn.microsoft.com/en-us/library/ms235286.aspx
https://en.wikipedia.org/wiki/X86_calling_conventions

I wonder how testing of any ASM function is passing at all.

Adding the "--enable-builtin-atomics" of which I was unaware,
finally solved the failures.

Regards
Marco

Re: [OMPI devel] PMIX on 2.0.0rc1 and cygwin build

[Marco Atzeri]

On 24/12/2015 06:10, Gilles Gouaillardet wrote:

Marco,

Thanks for the patch, i will apply the changes related to the missing
include files to master and PR to v2.x

on linux, libpmix.so does not depend on libopen-pal.
that being said, libpmix.so has undefined symbols related to hwloc and
libevent, and these symbols are defined in libopen-pal.so
i assume that is ok with linux but cygwin does not accept it.


circular dependency is hard to manage.


an other way to do things (and generally speaking, that could become the
way to go in a near future) is to use external hwloc and libevent (that
assumes of course cygwin provides these libraries and versions meet the
ompi requirements)


hwloc is already available as separate library, I will look to pack also 
libevent.



could you try to
configure --with-hwloc=external --with-libevent=external ...
and see if it helps ?


some time in the coming week


fwiw, with master you will soon be able to do the same thing with pmix
(e.g. configure --with-pmix=external ...)


I assume no one will really require PMI Exascale on cygwin.
So this should solve the issue anyway

Regards
Marco




Cheers,

Gilles

On 12/24/2015 3:42 AM, Marco Atzeri wrote:

building 2.0.0rc1 on cygwin I was stacked on
opal/mca/pmix/pmix1xx/pmix

Question:
- as pmix depends on hwloc and libevents, is it supposed to
  link against opal shared lib, is it supposed to be included
  in the opal shared lib or is it a circular dependency ?

I solved the build changing from shared to convenience library.

-lib_LTLIBRARIES = libpmix.la
+noinst_LTLIBRARIES = libpmix.la

as circular dependency will be a hell to manage with the
no-undefined flag.

The attached patch solves also

- several lacks of declaration for opal_output functions
  used in the ompi tree.
  They also require libmpi link vs lib@opal_lib_pre...@open-pal.la

- lack of declaration for several  functions
  like access, gethostname, usleep, ..

- add !defined(__CYGWIN__) on libevent2022/libevent/event.h
  as for current 1.8 and 1.10 code.


Please also note that usleep is marked as obsolescent on
Open Group Base Specifications Issue 6
http://pubs.opengroup.org/onlinepubs/009695399/functions/usleep.html
and it is missing on Issue7

With this patch it builds on cygwin 64 bit and passes the
same tests of 1.10.x code

Regards
Marco



___
devel mailing list
de...@open-mpi.org
Subscription:http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this 
post:http://www.open-mpi.org/community/lists/devel/2015/12/18453.php




___
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2015/12/18456.php

[OMPI devel] PMIX on 2.0.0rc1 and cygwin build

[Marco Atzeri]

building 2.0.0rc1 on cygwin I was stacked on
opal/mca/pmix/pmix1xx/pmix

Question:
- as pmix depends on hwloc and libevents, is it supposed to
  link against opal shared lib, is it supposed to be included
  in the opal shared lib or is it a circular dependency ?

I solved the build changing from shared to convenience library.

-lib_LTLIBRARIES = libpmix.la
+noinst_LTLIBRARIES = libpmix.la

as circular dependency will be a hell to manage with the
no-undefined flag.

The attached patch solves also

- several lacks of declaration for opal_output functions
  used in the ompi tree.
  They also require libmpi link vs lib@opal_lib_pre...@open-pal.la

- lack of declaration for several  functions
  like access, gethostname, usleep, ..

- add !defined(__CYGWIN__) on libevent2022/libevent/event.h
  as for current 1.8 and 1.10 code.


Please also note that usleep is marked as obsolescent on
Open Group Base Specifications Issue 6
  http://pubs.opengroup.org/onlinepubs/009695399/functions/usleep.html
and it is missing on Issue7

With this patch it builds on cygwin 64 bit and passes the
same tests of 1.10.x code

Regards
Marco

--- origsrc/openmpi-2.0.0rc1/ompi/Makefile.am   2015-12-18 22:52:51.0 
+0100
+++ src/openmpi-2.0.0rc1/ompi/Makefile.am   2015-12-23 06:49:07.003451100 
+0100
@@ -130,6 +130,7 @@ DIST_SUBDIRS = \
 lib_LTLIBRARIES = libmpi.la
 libmpi_la_SOURCES =
 libmpi_la_LIBADD = \
+   $(OMPI_TOP_BUILDDIR)/opal/lib@opal_lib_pre...@open-pal.la \
 datatype/libdatatype.la \
 debuggers/libdebuggers.la \
 mpi/c/libmpi_c.la \
--- origsrc/openmpi-2.0.0rc1/ompi/mca/coll/tuned/coll_tuned.h   2015-12-18 
22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/ompi/mca/coll/tuned/coll_tuned.h   2015-12-23 
06:49:07.013451100 +0100
@@ -21,6 +21,7 @@
 #include "ompi/mca/mca.h"
 #include "ompi/request/request.h"
 #include "ompi/mca/coll/base/coll_base_functions.h"
+#include "opal/util/output.h"
 
 /* also need the dynamic rule structures */
 #include "coll_tuned_dynamic_rules.h"
--- origsrc/openmpi-2.0.0rc1/ompi/mca/fbtl/base/fbtl_base_find_available.c  
2015-12-18 22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/ompi/mca/fbtl/base/fbtl_base_find_available.c  
2015-12-23 10:13:01.353793800 +0100
@@ -25,6 +25,7 @@
 #include "mpi.h"
 #include "ompi/constants.h"
 #include "opal/class/opal_list.h"
+#include "opal/util/output.h"
 #include "ompi/mca/mca.h"
 #include "opal/mca/base/base.h"
 #include "ompi/mca/fbtl/fbtl.h"
--- origsrc/openmpi-2.0.0rc1/opal/mca/base/base.h   2015-12-18 
22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/base/base.h   2015-12-23 09:54:43.169182900 
+0100
@@ -35,6 +35,7 @@
 #include "opal/mca/base/mca_base_var.h"
 #include "opal/mca/base/mca_base_framework.h"
 #include "opal/util/cmd_line.h"
+#include "opal/util/output.h"
 
 BEGIN_C_DECLS
 
--- origsrc/openmpi-2.0.0rc1/opal/mca/base/mca_base_component_repository.c  
2015-12-18 22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/base/mca_base_component_repository.c  
2015-12-23 09:58:25.202502900 +0100
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "opal/class/opal_list.h"
 #include "opal/mca/mca.h"
--- origsrc/openmpi-2.0.0rc1/opal/mca/btl/sm/btl_sm.c   2015-12-18 
22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/btl/sm/btl_sm.c   2015-12-23 
06:49:07.033451100 +0100
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 #ifdef HAVE_FCNTL_H
 #include 
 #endif  /* HAVE_FCNTL_H */
--- origsrc/openmpi-2.0.0rc1/opal/mca/btl/tcp/btl_tcp.h 2015-12-18 
22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/btl/tcp/btl_tcp.h 2015-12-23 
10:09:42.226504600 +0100
@@ -37,6 +37,7 @@
 #ifdef HAVE_NETINET_IN_H
 #include 
 #endif
+#include 
 
 /* Open MPI includes */
 #include "opal/mca/event/event.h"
--- origsrc/openmpi-2.0.0rc1/opal/mca/event/libevent2022/libevent/event.h   
2015-12-18 22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/event/libevent2022/libevent/event.h   
2015-12-23 06:49:07.053451200 +0100
@@ -56,7 +56,7 @@ extern "C" {
 /* For int types. */
 #include 
 
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
 #ifndef WIN32_LEAN_AND_MEAN
 #define WIN32_LEAN_AND_MEAN
 #endif
--- origsrc/openmpi-2.0.0rc1/opal/mca/mpool/base/mpool_base_tree.c  
2015-12-18 22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/mpool/base/mpool_base_tree.c  2015-12-23 
10:00:28.592679000 +0100
@@ -28,6 +28,7 @@
  * Description of the Registration Cache framework
  */
 
+#include 
 #include "opal_config.h"
 
 #include "opal/mca/mca.h"
--- origsrc/openmpi-2.0.0rc1/opal/mca/pmix/base/pmix_base_fns.c 2015-12-18 
22:52:51.0 +0100
+++ src/openmpi-2.0.0rc1/opal/mca/pmix/base/pmix_base_fns.c 2015-12-23 
10:05:17.804124200 +0100
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 
 #include "opal_stdint.h"
 #include "opal/class/opal_pointer_array.h"
--- origsrc/openmpi-2.0.0rc1/opal/mca/pmix/pmix1xx/pmix/Makefile.am 

Re: [OMPI devel] Open MPI v1.10.2rc1 available

[Marco Atzeri]

On 19/12/2015 17:35, Ralph Castain wrote:

Hello folks

Don’t want your holiday to be too boring, so we are also making
available the v1.10.2 release candidate for review. We won’t release
until sometime in January, but hopefully some of you will have a chance
to test it in the meantime. You’ll find it in the usual place:

http://www.open-mpi.org/software/ompi/v1.10/



Ralph,
please note that while v1.10.2rc1 is available
the v1.10.1 link is missing.

Regards
Marco

Re: [OMPI devel] 1.8.5....going once...going twice...

[Marco Atzeri]

On 4/24/2015 6:52 PM, Ralph Castain wrote:

Any last minute issues people need to report? Otherwise, this baby is going to 
ship

Paul: I will include your README suggestions as they relate to 1.8.5. Thanks, 
as always!
Ralph



attached patch to avoid the link chains

mpif77$(EXEEXT) -> mpifort$(EXEEXT) -> opal_wrapper$(EXEEXT)
mpif90$(EXEEXT) -> mpifort$(EXEEXT) -> opal_wrapper$(EXEEXT)

and replace with just

mpif77$(EXEEXT) -> opal_wrapper$(EXEEXT)
mpif90$(EXEEXT) -> opal_wrapper$(EXEEXT)

It is not a bug, but produces side effects with cygwin
build and package system when it drops the $(EXEEXT) from
the links and leaves with broken chains.

It should be innocuous on every other system

Regards
Marco






--- origsrc/openmpi-1.8.5rc3/ompi/tools/wrappers/Makefile.am2014-11-01 
01:29:50.0 +0100
+++ src/openmpi-1.8.5rc3/ompi/tools/wrappers/Makefile.am2015-04-25 
16:06:10.795666200 +0200
@@ -44,8 +44,8 @@
(cd $(DESTDIR)$(bindir); rm -f mpic++; $(LN_S) ompi_wrapper_script 
mpic++)
(cd $(DESTDIR)$(bindir); rm -f mpicxx; $(LN_S) ompi_wrapper_script 
mpicxx)
(cd $(DESTDIR)$(bindir); rm -f mpifort; $(LN_S) ompi_wrapper_script 
mpifort)
-   (cd $(DESTDIR)$(bindir); rm -f mpif77; $(LN_S) mpifort mpif77)
-   (cd $(DESTDIR)$(bindir); rm -f mpif90; $(LN_S) mpifort mpif90)
+   (cd $(DESTDIR)$(bindir); rm -f mpif77; $(LN_S) ompi_wrapper_script 
mpif77)
+   (cd $(DESTDIR)$(bindir); rm -f mpif90; $(LN_S) ompi_wrapper_script 
mpif90)
 if OMPI_WANT_JAVA_BINDINGS
(cp mpijavac.pl $(DESTDIR)$(bindir))
(cd $(DESTDIR)$(bindir); chmod +x mpijavac.pl; rm -f mpijavac; $(LN_S) 
mpijavac.pl mpijavac)
@@ -94,8 +94,8 @@
(cd $(DESTDIR)$(bindir); rm -f mpic++$(EXEEXT); $(LN_S) 
opal_wrapper$(EXEEXT) mpic++$(EXEEXT))
(cd $(DESTDIR)$(bindir); rm -f mpicxx$(EXEEXT); $(LN_S) 
opal_wrapper$(EXEEXT) mpicxx$(EXEEXT))
(cd $(DESTDIR)$(bindir); rm -f mpifort$(EXEEXT); $(LN_S) 
opal_wrapper$(EXEEXT) mpifort$(EXEEXT))
-   (cd $(DESTDIR)$(bindir); rm -f mpif77$(EXEEXT); $(LN_S) 
mpifort$(EXEEXT) mpif77$(EXEEXT))
-   (cd $(DESTDIR)$(bindir); rm -f mpif90$(EXEEXT); $(LN_S) 
mpifort$(EXEEXT) mpif90$(EXEEXT))
+   (cd $(DESTDIR)$(bindir); rm -f mpif77$(EXEEXT); $(LN_S) 
opal_wrapper$(EXEEXT) mpif77$(EXEEXT))
+   (cd $(DESTDIR)$(bindir); rm -f mpif90$(EXEEXT); $(LN_S) 
opal_wrapper$(EXEEXT) mpif90$(EXEEXT))
 if OMPI_WANT_JAVA_BINDINGS
(cp mpijavac.pl $(DESTDIR)$(bindir))
(cd $(DESTDIR)$(bindir); chmod +x mpijavac.pl; rm -f mpijavac; $(LN_S) 
mpijavac.pl mpijavac)

Re: [OMPI devel] 1.8.5rc2 released

[Marco Atzeri]

On 4/22/2015 11:19 PM, Jeff Squyres (jsquyres) wrote:




Question:
what is the scope of the new two shared libs

usr/bin/cygmpi_usempi_ignore_tkr-0.dll
usr/bin/cygmpi_usempif08-0.dll

in comparison to previous

usr/bin/cygmpi_mpifh-2.dll
usr/bin/cygmpi_usempi-1.dll

already present in 1.8.4 ?


All 4 were present in 1.8.4, too -- but it depends on your compiler which of 
the fortran libraries are compiled.

I'm guessing you upgraded your fortran compiler?


eventually just from 4.8.x to 4.9x



With an "old" fortran compiler, we build the "old" Open MPI "use mpi" Fortran 
bindings -- cygmpi_usempi-1.dll (which is basically some script-generated code).

With a "new" fortran compiler, we build the "new" Open MPI "use mpi" Fortran bindings -- 
cygmpi_usempi_ignore_tkr-0.dll.  This is the same Fortran bindings interface as the usempi library, but it uses a 
compiler extension (that was found by configure) that is effectively a (void*) equivalent in Fortran (the extension is 
called "Ignore TKR").  The code that is compiled into the usempi_ignore_tkr library is quite a bit simpler, 
cleaner, and more inclusive than the generated code.

The usempif08 library is the "use mpi_f08" bindings; it will only be built if you have a 
"new" Fortran compiler.


It seems I will need to add 2 two Fortran sub packages ...

Re: [OMPI devel] 1.8.5rc2 released

[Marco Atzeri]

On 4/22/2015 12:43 AM, Jeff Squyres (jsquyres) wrote:

In the usual location:

 http://www.open-mpi.org/software/ompi/v1.8/




Making all in mpi/fortran/use-mpi-f08
make[2]: Entering directory 
'/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc2-1.x86_64/build/ompi/mpi/fortran/use-mpi-f08'

  FCLD libmpi_usempif08.la
.libs/abort_f08.o: In function `mpi_abort_f08_':
/usr/src/debug/openmpi-1.8.5rc2-1/ompi/mpi/fortran/use-mpi-f08/abort_f08.F90:17: 
undefined reference to `ompi_abort_f'
/usr/src/debug/openmpi-1.8.5rc2-1/ompi/mpi/fortran/use-mpi-f08/abort_f08.F90:17:(.text+0xe): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`ompi_abort_f'

.libs/accumulate_f08.o: In function `mpi_accumulate_f08_':
/usr/src/debug/openmpi-1.8.5rc2-1/ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90:28: 
undefined reference to `ompi_accumulate_f'


Patch attached.

Question:
what is the scope of the new two shared libs

 usr/bin/cygmpi_usempi_ignore_tkr-0.dll
 usr/bin/cygmpi_usempif08-0.dll

in comparison to previous

 usr/bin/cygmpi_mpifh-2.dll
 usr/bin/cygmpi_usempi-1.dll

already present in 1.8.4 ?

REgards
Marco
--- origsrc/openmpi-1.8.5rc2/ompi/mpi/fortran/use-mpi-f08/Makefile.am   
2015-04-05 20:40:24.0 +0200
+++ src/openmpi-1.8.5rc2/ompi/mpi/fortran/use-mpi-f08/Makefile.am   
2015-04-22 15:39:46.739793600 +0200
@@ -805,6 +805,7 @@ endif
 libmpi_usempif08_la_LIBADD = \
 $(module_sentinel_file) \
 $(OMPI_MPIEXT_USEMPIF08_LIBS) \
+$(top_builddir)/ompi/mpi/fortran/mpif-h/libmpi_mpifh.la \
 $(top_builddir)/ompi/libmpi.la
 libmpi_usempif08_la_DEPENDENCIES = $(module_sentinel_file)
 libmpi_usempif08_la_LDFLAGS = -version-info $(libmpi_usempif08_so_version)

Re: [OMPI devel] 1.8.5rc1 is ready for testing

[Marco Atzeri]

On 4/20/2015 5:16 PM, Jeff Squyres (jsquyres) wrote:

I looked at this thread in a little more detail...

The question below is a little moot because of the change that was done to 
v1.8, but please humor me anyway.  :-)

Macro: I think you told me before, but I forget, so please refresh my memory: I 
seem to recall that there's a reason you're invoking autogen in a tarball, but 
I don't remember what it is.



Hi Jeff,

It is a standard best practice for cygwin package build.
Our package build system (cygport) has autoreconf as default
before configure..

90% of the time is not really needed, but some packages are really
a pain. So to avoid surprise we play safe.



I ask because in all POSIX cases at least, end users should be able to just 
untar, configure, make, make install -- they don't/shouldn't run autogen).  
I.e., it doesn't matter what version of Libtool end users have installed (or 
not!) because we bootstrapped the tarball with a Libtool version that we know 
works.  Even more specifically: the error you're running in to should not have 
happened with a plain tarball -- the only cases where I can think of it 
happening would be if you got a git clone and ran autogen, or if you got a 
tarball and (re-)ran autogen.


It is "got a tarball and (re-)ran autogen"

I can disable it and test anyway, if it is really needed, but
I will prefer that autogen.sh works as expected.

Regards
Marco

Re: [OMPI devel] 1.8.5rc1 is ready for testing

[Marco Atzeri]

tomorrow is fine .
I am testing octave-4.0.0-rc3 today
;-)


On 4/18/2015 9:13 PM, Ralph Castain wrote:

I am planning on rc2 on Monday, if you’d prefer to wait



On Apr 18, 2015, at 9:30 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:

Are you planning another rc or I should test the git stable repository ?

Re: [OMPI devel] 1.8.5rc1 is ready for testing

[Marco Atzeri]

Are you planning another rc or I should test the git stable repository ?


On 4/18/2015 5:10 PM, Ralph Castain wrote:

Should now be solved - it was a libtool compatibility issue, and I
updated the 1.8 libtool code


On Apr 18, 2015, at 7:57 AM, Marco Atzeri <marco.atz...@gmail.com
<mailto:marco.atz...@gmail.com>> wrote:

On 4/18/2015 1:01 PM, Jeff Squyres (jsquyres) wrote:

Marco --

I'm super-late to this -- did this issue get resolved?



Not that I am aware of.
I was busy on other things and I did not work further on the matter.

Suggestion for solving it ?

Re: [OMPI devel] 1.8.5rc1 is ready for testing

[Marco Atzeri]

On 4/7/2015 10:00 PM, Ralph Castain wrote:

What version of libtool do you have? We require 2.4.2 - newer versions don’t 
necessarily work, I fear.



2.4.6

for what I can see opal/mca/backtrace/configure.m4 exist on
the source tree

so it seems a lack of relative/absolute path when invoking

make[2]: Entering directory 
'/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/build/opal/libltdl'
CDPATH="${ZSH_VERSION+.}:" && cd 
/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl 
&& aclocal-1.15 -I ../../config
aclocal-1.15: error: ../../config/autogen_found_items.m4:304: file 
'opal/mca/backtrace/configure.m4' does not exist
Makefile:539: recipe for target 
'/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl/aclocal.m4' 
failed
make[2]: *** 
[/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl/aclocal.m4] 
Error 1

Re: [OMPI devel] 1.8.5rc1 is ready for testing

[Marco Atzeri]

On 4/5/2015 11:42 PM, Ralph Castain wrote:

Usual place:

http://www.open-mpi.org/software/ompi/v1.8/



building on cygwin64

Making all in libltdl
make[2]: Entering directory 
'/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/build/opal/libltdl'
CDPATH="${ZSH_VERSION+.}:" && cd 
/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl 
&& aclocal-1.15 -I ../../config
aclocal-1.15: error: ../../config/autogen_found_items.m4:304: file 
'opal/mca/backtrace/configure.m4' does not exist
Makefile:539: recipe for target 
'/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl/aclocal.m4' 
failed
make[2]: *** 
[/pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/src/openmpi-1.8.5rc1/opal/libltdl/aclocal.m4] 
Error 1




configuration:

   --disable-mca-dso \
--disable-sysv-shmem \
--enable-cxx-exceptions \
--with-threads=posix \
--without-cs-fs \
--with-mpi-param_check=always \
--enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv

Re: [OMPI devel] 1.8.4rc4 now out for testing

[Marco Atzeri]

On 12/14/2014 12:06 AM, Ralph Castain wrote:

Hi folks

I’ve rolled up the bug fixes so far, including the thread-multiple
performance fix. So please give this one a whirl

http://www.open-mpi.org/software/ompi/v1.8/

Ralph



No regression on Cygwin 64 bit

Only and usual FAIL: atomic_cmpset_noinline.exe

Tested also OSU benchmarks 4.4.1
Only test failing (as already seen)
  mpi/pt2pt/osu_latency_mt.exe
  mpi/pt2pt/osu_multi_lat.exe

and I am not sure that I am correctly running them.
All the other tests are passed

./mpi/collective/osu_allgather.exe
./mpi/collective/osu_allgatherv.exe
./mpi/collective/osu_allreduce.exe
./mpi/collective/osu_alltoall.exe
./mpi/collective/osu_alltoallv.exe
./mpi/collective/osu_barrier.exe
./mpi/collective/osu_bcast.exe
./mpi/collective/osu_gather.exe
./mpi/collective/osu_gatherv.exe
./mpi/collective/osu_reduce.exe
./mpi/collective/osu_reduce_scatter.exe
./mpi/collective/osu_scatter.exe
./mpi/collective/osu_scatterv.exe
./mpi/one-sided/osu_acc_latency.exe
./mpi/one-sided/osu_cas_latency.exe
./mpi/one-sided/osu_fop_latency.exe
./mpi/one-sided/osu_get_acc_latency.exe
./mpi/one-sided/osu_get_bw.exe
./mpi/one-sided/osu_get_latency.exe
./mpi/one-sided/osu_put_bibw.exe
./mpi/one-sided/osu_put_bw.exe
./mpi/one-sided/osu_put_latency.exe
./mpi/pt2pt/osu_bibw.exe
./mpi/pt2pt/osu_bw.exe
./mpi/pt2pt/osu_latency.exe
./mpi/pt2pt/osu_mbw_mr.exe

[OMPI devel] oshmem only supports Linux ?

[Marco Atzeri]

Hi,
I had the impression that the scope of using autotools is
to check for features not platforms.


*** OSHMEM Configuration options
checking if want oshmem... yes
configure: WARNING: OpenSHMEM support was requested, but currently
configure: WARNING: only supports Linux.
configure: error: Cannot continue
*** ERROR: configure failed

last time, some time ago, I built 1.9.x with oshmem this statement,
configure error, was not present.

Which feature is really needed ?

Regards
Marco

Re: [OMPI devel] 1.8.2rc2 ready for test

[Marco Atzeri]

On 24/07/2014 15:52, Ralph Castain wrote:

Oshmem should be enabled by default now


Ok,
so please reverse the configure switch

  --enable-oshmem Enable building the OpenSHMEM interface 
(disabled by default)


I will test enabling it in the meantime.

Regards
Marco

Re: [OMPI devel] Bad parameter in file oob_tcp.c

[Marco Atzeri]

On 05/03/2014 04:06, Ralph Castain wrote:

The code generating the error is here:

 in->sin_addr.s_addr = inet_addr(host);
 if (in->sin_addr.s_addr == INADDR_ANY) {
 return ORTE_ERR_BAD_PARAM;
 }


The address is resolving to INADDR_ANY instead of a regular address.
Does cygwin require some other method for resolving a hostname to an IP
address?

Ralph




in theory should be transparent using the same as windows.
But I need to understand if there is any difference in formal behavior

Regards
Marco

[OMPI devel] Bad parameter in file oob_tcp.c

[Marco Atzeri]

noted on cygwin with 1.7.4 and on 1.7.5rc1

$ mpirun -n 4 ./hello_c.exe
[MATZERI:06212] [[62628,1],0] ORTE_ERROR_LOG: Bad parameter in file 
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c 
at line 292
[MATZERI:05620] [[62628,1],1] ORTE_ERROR_LOG: Bad parameter in file 
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c 
at line 292
[MATZERI:06892] [[62628,1],2] ORTE_ERROR_LOG: Bad parameter in file 
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c 
at line 292
[MATZERI:03908] [[62628,1],3] ORTE_ERROR_LOG: Bad parameter in file 
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c 
at line 292
Hello, world, I am 1 of 4, (Open MPI v1.7.5rc1, package: Open MPI 
marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
Hello, world, I am 2 of 4, (Open MPI v1.7.5rc1, package: Open MPI 
marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
Hello, world, I am 3 of 4, (Open MPI v1.7.5rc1, package: Open MPI 
marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
Hello, world, I am 0 of 4, (Open MPI v1.7.5rc1, package: Open MPI 
marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)


any idea what could be the cause ?

I don't remember it in previous 1.7.x releases

the relevant code is:

if ((rc = parse_uri(pop->af_family, pop->net, pop->port, (struct 
sockaddr*) )) != ORTE_SUCCESS) {

ORTE_ERROR_LOG(rc);

Regards
Marco

Re: [OMPI devel] v1.7.5rc1 posted

[Marco Atzeri]

On 04/03/2014 20:35, Hjelm, Nathan T wrote:

Fixed and CMR'ed to 1.7.5.

-Nathan



confirmed

thanks

Re: [OMPI devel] v1.7.5rc1 posted

[Marco Atzeri]

On 02/03/2014 03:13, Ralph Castain wrote:

In the usual place:

http://www.open-mpi.org/software/ompi/v1.7/

Please subject this to your best tests as we hope to roll this (plus bug fixes) 
to 1.8.0 at the end of the month. This includes the new OSHMEM support, plus a 
completely updated MPI-3 compliant one-sided implementation.

Scheduled release date: Mar 10

Thanks
Ralph





/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/ompi/mca/osc/rdma/osc_rdma_data_move.c: 
In function 'osc_rdma_accumulate_buffer':
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/ompi/mca/osc/rdma/osc_rdma_data_move.c:481:28: 
error: 'header' undeclared (first use in this function)

 primitive_count *= header->hdr_target_count;
^
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/ompi/mca/osc/rdma/osc_rdma_data_move.c:481:28: 
note: each undeclared identifier is reported only once for each function 
it appears in

Makefile:1660: recipe for target 'osc_rdma_data_move.lo' failed
make[2]: *** [osc_rdma_data_move.lo] Error 1



suggestions ? The relevant code is this one :


#if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
if (proc->proc_arch != ompi_proc_local()->proc_arch) {
ompi_datatype_t *primitive_datatype = NULL;
uint32_t primitive_count;
size_t buflen;

ompi_osc_base_get_primitive_type_info(datatype, 
_datatype, _count);

primitive_count *= header->hdr_target_count;

/* figure out how big a buffer we need */
ompi_datatype_type_size(primitive_datatype, );
buflen *= primitive_count;

buffer = malloc (buflen);
if (OPAL_UNLIKELY(NULL == buffer)) {
return OMPI_ERR_OUT_OF_RESOURCE;
}

osc_rdma_copy_on_recv (buffer, source, source_len, proc, count, 
datatype);

}
#endif

Re: [OMPI devel] 1.7.5 status

[Marco Atzeri]

On 13/02/2014 16:36, Ralph Castain wrote:

Hi Marco

Quick question for you: we don't support Windows any more anyway. If we just 
remove the #if WIN32 cruft, would that solve the problem?




in theory yes.


Regards
Marco

Re: [OMPI devel] 1.7.5 status

[Marco Atzeri]

On 12/02/2014 04:18, Ralph Castain wrote:

Things are looking relatively good - I see two recurring failures:

1. idx_null - no idea what that test does, but it routinely fails

2. intercomm_create - this is the 3-way connect/accept/merge. Nathan - I 
believe you had a fix for that?

Ralph




openmpi-1.7.5a1r30692-1 builds fine con cygwin64
only failure the already know
https://svn.open-mpi.org/trac/ompi/ticket/4195


Attached patch equivalent to what is already on trunk for ohsmem

Regards
Marco
--- origsrc/openmpi-1.7.5a1r30692/oshmem/include/shmem.h.in 2014-02-12 
01:14:52.0 +0100
+++ src/openmpi-1.7.5a1r30692/oshmem/include/shmem.h.in 2014-02-12 
21:10:52.337417500 +0100
@@ -14,7 +14,7 @@

 #include  /* include for ptrdiff_t */

-#if defined(WIN32) || defined(_WIN32)
+#if defined(WIN32) && !defined(__CYGWIN__)
 #define OSHMEM_COMPLEX_TYPE(type)
 #else
 #if defined(c_plusplus) || defined(__cplusplus)
@@ -35,7 +35,7 @@


 #ifndef OSHMEM_DECLSPEC
-#  if defined(WIN32) || defined(_WIN32)
+#  if defined(WIN32) && !defined(__CYGWIN__)
 #if defined(OSHMEM_IMPORTS)
 #  define OSHMEM_DECLSPEC__declspec(dllimport)
 #else
--- origsrc/openmpi-1.9a1r30128/oshmem/mca/memheap/base/memheap_base_alloc.c
2014-01-07 03:05:02.0 +0100
+++ src/openmpi-1.9a1r30128/oshmem/mca/memheap/base/memheap_base_alloc.c
2014-01-09 15:36:22.121579700 +0100
@@ -21,6 +21,7 @@

 #include 
 #include 
+#include 

 #if defined(MPAGE_ENABLE) && (MPAGE_ENABLE > 0)
 #include 
@@ -215,7 +216,7 @@ static int _shm_attach(map_segment_t *s,

 shm_context = use_hp;

-flags = IPC_CREAT | IPC_EXCL | SHM_R | SHM_W;
+flags = IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR;
 #if defined (SHM_HUGETLB)
 flags |= (use_hp ? SHM_HUGETLB : 0);
 #endif
--- origsrc/openmpi-1.9a1r30128/oshmem/mca/memheap/ptmalloc/malloc.c
2014-01-07 03:05:02.0 +0100
+++ src/openmpi-1.9a1r30128/oshmem/mca/memheap/ptmalloc/malloc.c
2014-01-10 14:16:10.423949900 +0100
@@ -487,6 +487,9 @@ MAX_RELEASE_CHECK_RATE   default: 255 un
 #define WIN32 1
 #endif  /* _WIN32 */
 #endif  /* WIN32 */
+#if defined(__CYGWIN__) /* WORKAROUND as something is pulling the wrong def*/
+#undef WIN32
+#endif
 #ifdef WIN32
 #define WIN32_LEAN_AND_MEAN
 #include 

Re: [OMPI devel] 1.7.4rc2 is out

[Marco Atzeri]

On 28/01/2014 04:54, Jeff Squyres (jsquyres) wrote:

In the usual location:

 http://www.open-mpi.org/software/ompi/v1.7/

Lots of changes since 1.7.4rc1, but we didn't keep a good NEWS file between the 
two, so I can't list them all here.



On cygwin 64 bit, except for the known noinline failures
https://svn.open-mpi.org/trac/ompi/ticket/4195

everthing is fine.

Regards
Marco

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

[marco atzeri]

Il 1/11/2014 7:54 AM, marco atzeri ha scritto:

Il 1/11/2014 4:28 AM, Paul Hargrove ha scritto:

Jeff and I iterated a bit off-list and opal/util/path.c in tonight's
trunk tarball (1.9a1r30255) works for all of my systems.
With the help of Jeff's recently-enhanced test/util/opal_path_nfs.c I
was able to verify that NFS mounts are now correctly identified on the
*BSD systems (and still correct on Linux, Mac OSX, and Solaris).

Marco,
   Can you please verify on Cygwin?

-Paul



starting now, but it will take some time ;-)

Regards
Marco




1.9a1r30255 with the two CYGWIN specific patches for oshmem
https://svn.open-mpi.org/trac/ompi/ticket/4085#comment:6

build fines on cygwin 64bit
No issue on "opal/util/path.c"

Marco

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

[marco atzeri]

Il 1/11/2014 4:28 AM, Paul Hargrove ha scritto:

Jeff and I iterated a bit off-list and opal/util/path.c in tonight's
trunk tarball (1.9a1r30255) works for all of my systems.
With the help of Jeff's recently-enhanced test/util/opal_path_nfs.c I
was able to verify that NFS mounts are now correctly identified on the
*BSD systems (and still correct on Linux, Mac OSX, and Solaris).

Marco,
   Can you please verify on Cygwin?

-Paul



starting now, but it will take some time ;-)

Regards
Marco

Re: [OMPI devel] shared lib version on trunk

[marco atzeri]

Il 1/10/2014 3:50 PM, Jeff Squyres (jsquyres) ha scritto:

On Jan 10, 2014, at 9:48 AM, marco atzeri <> wrote:


building openmpi-1.9a1r30128-1, I notice
-
# Version information for libmpi.
current=0
age=0
revision=0
--

while on 1.7.3 is
--
# Version information for libmpi.
current=3
age=2
revision=0
--

Is this intentional ?


Yes.  We keep it 0/0/0 on the trunk (since the trunk is for developers only, we 
don't really need to care about ABI issues there), and only update the versions 
on the release branch more-or-less immediately before individual releases.



nice to know, I was wondering if something else went wrong.

[OMPI devel] shared lib version on trunk

[marco atzeri]

building openmpi-1.9a1r30128-1, I notice

-
# Version information for libmpi.
current=0
age=0
revision=0
--

while on 1.7.3 is
--
# Version information for libmpi.
current=3
age=2
revision=0
--


Is this intentional ?

Regards
Marco

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

[marco atzeri]

Il 1/10/2014 5:00 AM, Paul Hargrove ha scritto:

The following might be helpful:
http://stackoverflow.com/questions/1653163/difference-between-statvfs-and-statfs-system-calls

It seems to indicate that even if one does find a statfs() function,
there are multiple os-dependent versions and it should therefore be
avoided.  Since statvfs() is defined by POSIX, it should be preferred.

If I am not mistaken, reordering the #if logic in path.c to use *only*
statvfs() when it is available (and *not* trying both as is done now)
would resolve the problems I am seeing with NetBSD and Solaris WITHOUT
any need to change the configure logic.  However, if one does want to
keep the current logic (or at least something similar) it looks like
configure should not assume statfs() is available without *also*
confirming that "struct statfs" is available.

-Paul



statvfs() is available on CYGWIN,
http://cygwin.com/cygwin-api/compatibility.html#std-susv4

so no issue to use it as default for me

Thanks
Marco

Re: [OMPI devel] 1.7.4rc1 test failure : cygwin 64 bit

[marco atzeri]

Il 1/7/2014 2:54 PM, George Bosilca ha scritto:

Can you try with the latest trunk please?

Also if things are not going well with the trunk please provide the 
opal_config.h file.

   Thanks,
 George.



same failures
opal_config.h for openmpi-1.9a1r30128-1 attached.

Sorry for delay but building for cygwin is very slow
and I just noticed that some patches for 1.7
were never applied  to trunk plus I hit some additional issues

I will open a new ticket with patches for trunk as soon
I solve all the issue

Marco





opal_config.h.bz2
Description: Binary data

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

[marco atzeri]

Il 1/9/2014 5:10 AM, Ralph Castain ha scritto:

Actually, as I look at it, the logic escapes me anyway. Basically, you
only have two options - use the vfs struct for Sun, and use fs struct
for everything else. I'm not aware of any other choice, and indeed the
list of all the systems for the latter actually is intended to amount to
"anything else".

So I just changed it to an "else" statement in the trunk and scheduled
it for 1.7.4 if it passes muster - see how this works for you.

Ralph



Ralph,
please note that there are other similar cases in the same file

in "bool opal_path_nfs" function at row 434 and 462

the one at 489 is a multiple if with no default case,
so the code will fail to perform for any architecture
no reported there, like CYGWIN, and it is very hard to notice

In general this type of "ifdefined" around platform
are very bad for portability or platform evolution.
Adding a new platform will be a hell of work.

The Autoconf approach to portability "should be" to test
for features, not for versions or platform.

Regards
Marco

[OMPI devel] 1.7.4rc1 test failure : cygwin 64 bit

[marco atzeri]

Failures on cygwin 64bit with gcc-4.8.2.
Notes:
- cygwin 32bit gives no failure
- These failures are not new, they were also present in openmpi-1.7.3-1
   and previous

-
--> Testing atomic_spinlock_noinline.exe
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6476 Segmentation fault  (core dumped) $* $threads

- 1 threads: Failed
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6680 Segmentation fault  (core dumped) $* $threads

- 2 threads: Failed
- 4 threads: Passed
- 5 threads: Passed
- 8 threads: Passed
FAIL: atomic_spinlock_noinline.exe
--> Testing atomic_math.exe
- 1 threads: Passed
- 2 threads: Passed
- 4 threads: Passed
- 5 threads: Passed
- 8 threads: Passed
PASS: atomic_math.exe
--> Testing atomic_math_noinline.exe
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6676 Segmentation fault  (core dumped) $* $threads

- 1 threads: Failed
- 2 threads: Passed
- 4 threads: Passed
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6976 Segmentation fault  (core dumped) $* $threads

- 5 threads: Failed
- 8 threads: Passed
FAIL: atomic_math_noinline.exe
--> Testing atomic_cmpset.exe
- 1 threads: Passed
- 2 threads: Passed
- 4 threads: Passed
- 5 threads: Passed
- 8 threads: Passed
PASS: atomic_cmpset.exe
--> Testing atomic_cmpset_noinline.exe
assertion "opal_atomic_cmpset_32(, old32, new32) == 1" failed: 
file 
"/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", 
line 105, function: main
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6248 Aborted (core dumped) $* $threads

- 1 threads: Failed
assertion "opal_atomic_cmpset_32(, old32, new32) == 1" failed: 
file 
"/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", 
line 105, function: main
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  2556 Aborted (core dumped) $* $threads

- 2 threads: Failed
assertion "opal_atomic_cmpset_32(, old32, new32) == 1" failed: 
file 
"/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", 
line 105, function: main
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  6164 Aborted (core dumped) $* $threads

- 4 threads: Failed
assertion "opal_atomic_cmpset_32(, old32, new32) == 1" failed: 
file 
"/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", 
line 105, function: main
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  5312 Aborted (core dumped) $* $threads

- 5 threads: Failed
assertion "opal_atomic_cmpset_32(, old32, new32) == 1" failed: 
file 
"/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", 
line 105, function: main
/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: 
line 8:  7948 Aborted (core dumped) $* $threads

- 8 threads: Failed
FAIL: atomic_cmpset_noinline.exe

3 of 8 tests failed

Re: [OMPI devel] 1.7.x support statement

[marco atzeri]

Il 10/8/2013 4:42 PM, Jeff Squyres (jsquyres) ha scritto:



Could you also run the built-in "trivial" suite?  It's just hello world and MPI 
ring in C, C++, Fortran (if you have C++/Fortran support).

FWIW: this is basically what Absoft does for us: they do the builds, and then 
build/run the trivial suite just to make sure it's nominally working.



attached the only dump I found plus the log of the run on 1.7.2.
Is this the expected results?  It seems a bit thin.

Regards
Marco



$VAR1 = {
  'trivial' => {
'append_path' => undef,
'result_message' => 'Success',
'full_section_name' => 'test get: trivial',
'test_result' => 1,
'module_data' => {
  'directory' => '/tmp/scratch1/sources/test_get__trivial'
},
'prepare_for_install' => 'MTT::Common::Copytree::PrepareForInstall',
'prepend_path' => undef,
'setenv' => undef,
'refcount' => 0,
'simple_section_name' => 'trivial',
'have_new' => 1,
'module_name' => 'MTT::Test::Get::Trivial',
'start_timestamp' => 1381258364,
'unsetenv' => undef
  }
};
*** MTT: ./client/mtt --scratch /tmp/scratch1 --file ../trivial.ini --verbose 
--print-time
*** Running on IT-Marco-Atzeri
*** Main scratch tree: /tmp/scratch1
*** Fast scratch tree: /tmp/scratch1
*** Reporter initializing
*** Reporter initialized
*** MPI Get phase starting
*** MPI Get phase complete
>> Phase: MPI Get
   Started:   Tue Oct  8 21:19:14 2013
   Stopped:   Tue Oct  8 21:19:14 2013
   Elapsed:   00:00:00 0.02u 0.02s
   Total elapsed: 00:00:00 0.02u 0.02s
*** MPI Install phase starting
*** MPI Install phase complete
>> Phase: MPI Install
   Started:   Tue Oct  8 21:19:14 2013
   Stopped:   Tue Oct  8 21:19:14 2013
   Elapsed:   00:00:00 0.00u 0.00s
   Total elapsed: 00:00:00 0.02u 0.02s
*** Test Get phase starting
>> Test Get: [test get: trivial]
   Checking for new test sources...
   Failed to get new test sources: File already exists: hello.c
*** Test Get phase complete
>> Phase: Test Get
   Started:   Tue Oct  8 21:19:14 2013
   Stopped:   Tue Oct  8 21:19:15 2013
   Elapsed:   00:00:01 0.02u 0.00s
   Total elapsed: 00:00:01 0.05u 0.03s
*** Test Build phase starting
>> Test Build [test build: trivial]
*** Test Build phase complete
>> Phase: Test Build
   Started:   Tue Oct  8 21:19:15 2013
   Stopped:   Tue Oct  8 21:19:15 2013
   Elapsed:   00:00:00 0.00u 0.00s
   Total elapsed: 00:00:01 0.05u 0.03s
*** Test Run phase starting
>> Test Run [trivial]
*** Run test phase complete
>> Phase: Test Run
   Started:   Tue Oct  8 21:19:15 2013
   Stopped:   Tue Oct  8 21:19:16 2013
   Elapsed:   00:00:01 0.00u 0.03s
   Total elapsed: 00:00:02 0.05u 0.06s
>> Phase: Trim
   Started:   Tue Oct  8 21:19:16 2013
   Stopped:   Tue Oct  8 21:19:16 2013
   Elapsed:   00:00:00 0.00u 0.00s
   Total elapsed: 00:00:02 0.05u 0.06s
*** Reporter finalizing
*** Reporter finalized

Re: [OMPI devel] 1.7.x support statement

[marco atzeri]

Il 10/5/2013 1:35 AM, Jeff Squyres (jsquyres) ha scritto:

On Oct 4, 2013, at 8:38 AM, marco atzeri  wrote:


At first glance it does not seems particular user friendly nor with a clear 
HOWTO guide for good start.


How's this for a start:

 https://svn.open-mpi.org/trac/mtt/wiki/OMPITesting


Additional LWP::Protocol::https is not available so
some expectation are not fullfilled.


We might be able to work around this.


Anything as simple as
   http://mvapich.cse.ohio-state.edu/benchmarks/
is available for performing MTT tests ?


Let me clarify: MTT is the engine to run MPI tests -- it's not MPI tests or 
benchmarks itself.  MTT is simply a way to download the nightly tarball, build 
it N ways, get lots of tests (e.g., the OSU benchmarks), compile each of them 
against each of the N OMPI builds, and then run each of those tests M different 
ways, and then submit those results up to our community database.

Once you have MTT up and running, it can run fairly largely automated -- mine 
runs in a cron job, for example.

Make sense?



Jeff,
automating build on my hardware is a bit too much ;-)
as it is just a normal notebook and building on cygwin is a
slow process.

Attached the outcome of testing with the default developer.ini
and the installed 1.7.2.
I assume mtt is working as expected. Correct ?

Regards
Marco




hostname: IT-Marco-Atzeri
uname: CYGWIN_NT-6.1-WOW64 IT-Marco-Atzeri 1.7.25(0.270/5/3) 2013-08-31 20:39 
i686 Cygwin
who am i: 

+-+-+-+--+--+--+--+--++
| Phase   | Section | MPI Version | Duration | Pass | Fail | Time 
out | Skip | Detailed report
|
+-+-+-+--+--+--+--+--++
| MPI Install | my installation | 1.7.2   | 00:06| 1|  |
  |  | 
MPI_Install-my_installation-my_installation-1.7.2-my_installation.html |
+-+-+-+--+--+--+--+--++


Total Tests:1
Total Failures: 0
Total Passed:   1
Total Duration: 6 secs. (00:06)





+--+--+
| Field| Value|
+--+--+
| bitness  | 0|
| compiler_name| unknown  |
| compiler_version | unknown  |
| duration | 6 seconds|
| endian   | 0|
| exit_signal  | -1   |
| exit_value   | 0|
| merge_stdout_stderr  | 0|
| mpi_install_section_name | my installation  |
| mpi_name | my installation  |
| mpi_version  | 1.7.2|
| os_name  | CYGWIN_NT-6.1-WOW64  |
| os_version   | 2013-08-31 20:39 |
| phase| MPI Install  |
| platform_hardware| i686 |
| platform_type| unknown  |
| start_timestamp  | 1381086101   |
| start_timestamp_human| Sun Oct  6 19:01:41 2013 |
| vpath_mode   | 0|
|  |  |
|  |  |
+--+--+

Re: [OMPI devel] 1.7.x support statement

[marco atzeri]

Il 10/4/2013 1:47 PM, Jeff Squyres (jsquyres) ha scritto:

Good call; yes.

Marco: is there any chance you can run Open MPI through the MPI Testing Tool 
(MTT) on a regular basis, and submit your results to mtt.open-mpi.org?

You can run as few or as many tests a night as you want.  For example, the 
Absoft compiler company runs only hello world and ring MPI tests each night 
(i.e., their goal is to ensure that everything is *compiling* correctly with 
their compiler, and then they only have to run a small number of tests to 
ensure that stuff is actually running properly).

I'd be happy to chat with you about this to get you started with MTT.


Jeff,
At first glance it does not seems particular user friendly nor with a 
clear HOWTO guide for good start.


Additional LWP::Protocol::https is not available so
some expectation are not fullfilled.

Anything as simple as
   http://mvapich.cse.ohio-state.edu/benchmarks/
is available for performing MTT tests ?

Regards
Marco

Re: [OMPI devel] 1.7.x support statement

[marco atzeri]

Il 10/4/2013 1:08 PM, Jeff Squyres (jsquyres) ha scritto:

This is in the README -- is it still accurate?  I'm thinking that all Solaris support 
should move to the "lightly but not fully tested" category, for example:

-
- Systems that have been tested are:
   - Linux (various flavors/distros), 32 bit, with gcc
   - Linux (various flavors/distros), 64 bit (x86), with gcc, Absoft,
 Intel, Portland, and Oracle Solaris Studio 12.3 compilers (*)
   - OS X (10.5, 10.6, 10.7), 32 and 64 bit (x86_64), with gcc and
 Absoft compilers (*)
   - Oracle Solaris 10 and 11, 64 bit (SPARC, i386, x86_64),
 with Oracle Solaris Studio 12.2 and 12.3

   (*) Be sure to read the Compiler Notes, below.

- Other systems have been lightly (but not fully tested):
   - Other 64 bit platforms (e.g., Linux on PPC64)
   - 32-bit Solaris
-



you can add on the "Other systems"
  Cygwin 32 & 64 bit with gcc

Regards
Marco

Re: [OMPI devel] Fwd: basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

[marco atzeri]

Il 7/11/2013 1:47 PM, Vasiliy ha scritto:

I've also tracked down that problem with 'test-driver'. Look at that:

$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
...



http://cygwin.com/ml/cygwin-apps/2013-07/msg00102.html

Regards
Marco

Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries

[marco atzeri]

Il 7/9/2013 2:01 PM, Vasiliy ha scritto:

Hi, Marco,

It is a looong string of characters, times as yours, and I'm actually
making a DSO build with everything included. Yes, it is the
bleeding-edge, however, patched Open MPI version 1.9a1 sources, on
Cygwin 64-bit version 1.7.21-6.

I have updated dozens of Cygwin packages to their 'bleeding-edge'
revisions, and successfully tested and compiled many of those,
flexible enough, further with -Ofast and "plus" optimization for my
projects. This has resulted in a tremendous speed increase, full
multithreading, and hot deliverables due to faster execution time.


already building first openmpi package some months ago was bleeding edge 
;-)


You are welcome to the party and let me know how proceed with dso;
on my build it is disabled on purpose as I was not able to build it also
on 32bit due to the unclear dependency tree.

the undefined warning is usually releated to some type of

  LDFLAGS="-Wl,-no-undefined"

variants needed.
Unfortunately latest gcc does not ignore any more the "-no-undefined"
as unknown word and passing it to libtool is becoming a bit harder
that was in the past.

Please remind that Cygwin 64 is also bleeding-edge; it is a good beta
but still a beta.


While I don't represent any organization view it's still an amateur
work done to the detriment of time for job hunting. I probably need to
pay more attention to the latter, so, to find out if I could complete
a DSO build before the hunting season starts. There is a well-funded
hope, though.


I can not help here. Writing software is not my main activity, just a
side hobby.



Regards,
Vasiliy



Regards
Marco

Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries

[marco atzeri]

Il 7/8/2013 9:00 PM, Vasiliy ha scritto:

I haven't checked that yet, however, from my experience, creating a
shared library manually from the same compiled objects never was a
problem at a later stage, it's usually because of Makefile's
inconsistent dependencies ordering:

$ uname -srvmo
CYGWIN_NT-6.1 1.7.21(0.267/5/3) 2013-06-28 10:03 x86_64 Cygwin


Making all in debuggers
make[2]: Entering directory
'/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers'
   CC   libdebuggers_la-ompi_debuggers.lo
   CCLD libdebuggers.la
   CC   ompi_debugger_canary.lo
   CCLD libompi_debugger_canary.la
   CC   libompi_dbg_msgq_la-ompi_msgq_dll.lo
   CC   libompi_dbg_msgq_la-ompi_common_dll.lo
   CCLD libompi_dbg_msgq.la
libtool: warning: undefined symbols not allowed in
x86_64-unknown-cygwin shared libraries
make[2]: Leaving directory
'/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers'




Hi Vasiliy
how do you called configure ?

I have not tested 1.9 on cygwin 64, but
1.7.1 cygwin64 package was built with

configure \
LDFLAGS="-Wl,--export-all-symbols -Wl,-no-undefined"  \
--disable-mca-dso \
--disable-sysv-shmem \
--without-udapl \
--enable-cxx-exceptions \
--with-threads=posix \
--without-cs-fs \
--enable-heterogeneous \
--with-mpi-param_check=always \
--enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv


Regards
Marco

Re: [OMPI devel] Open MPI 1.7rc9 tarballs up

[marco atzeri]

On 3/28/2013 10:33 PM, Barrett, Brian W wrote:

All -

What we dearly hope is the final release candidate of 1.7, 1.7rc9,is up at
the usual place.  I would really like to release this early next week, so
if we could all test, that would be great.

   http://www.open-mpi.org/software/ompi/v1.7/

Thanks!

Brian



just as info:
in addition to cygwin 32bit, 1.7rc9 also builds and
runs fine on current "alpha" cygwin 64bit

Regards
Marco

Re: [OMPI devel] 1.7rc8 is posted

[marco atzeri]

On 2/27/2013 6:52 PM, Jeff Squyres (jsquyres) wrote:

The goal is to release 1.7 (final) by the end of this week.  New rc posted with 
fairly small changes:

 http://www.open-mpi.org/software/ompi/v1.7/

- Fix wrong header file / compilation error in bcol
- Support MXM STREAM for isend and irecv
- Make sure "mpirun " fails with $status!=0
- Bunches of cygwin minor fixes
- Make sure the fortran compiler supports BIND(C) with LOGICAL for the F08 
bindings
- Fix --disable-mpi-io with the F08 bindings



builds and passes tests on cygwin

Regards
Marco

Re: [OMPI devel] v1.7.0rc7

[marco atzeri]

On 2/26/2013 3:37 AM, Jeff Squyres (jsquyres) wrote:

Marco --

Is it just these 2 patches:

r28059 [[BR]]
Patch for Cygwin support: use correct DSO/shared library prefix and
suffix.  Thanks to Marco Atzeri for reporting the issue and providing
an initial patch.

r28060 [[BR]]
Patch for Cygwin support: Use S_IRWXU for shmget() and include
.  Thanks to Marco Atzeri for reporting the issue and
providing an initial patch.




plus the additional ones

   ERROR.patch : ERROR is already defined, so another label
 is needed for "goto ERROR"
   interface.patch : same for interface , it seems a
 struct somewhere else
   min.patch : min already defined as macro
 (I saw in the source also a MIN macro defined)
   mpifh.patch : to avoid undefined error
 libmpi_mpifh_la_LIBADD needs
 $(top_builddir)/ompi/libmpi.la
   winsock.patch : defense against  usage

attached here
http://www.open-mpi.org/community/lists/devel/2012/12/11855.php
https://svn.open-mpi.org/trac/ompi/ticket/3437

All test passed, but I noticed these warnings:

  CC   to_self.o
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c: 
In function ‘create_indexed_constant_gap_ddt’:
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:48:5: 
warning: ‘MPI_Type_struct’ is deprecated (declared at 
../../ompi/include/mpi.h:1579): MPI_Type_struct is superseded by 
MPI_Type_create_struct in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c: 
In function ‘create_indexed_gap_ddt’:
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:89:5: 
warning: ‘MPI_Address’ is deprecated (declared at 
../../ompi/include/mpi.h:1057): MPI_Address is superseded by 
MPI_Get_address in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:90:5: 
warning: ‘MPI_Address’ is deprecated (declared at 
../../ompi/include/mpi.h:1057): MPI_Address is superseded by 
MPI_Get_address in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:93:5: 
warning: ‘MPI_Type_struct’ is deprecated (declared at 
../../ompi/include/mpi.h:1579): MPI_Type_struct is superseded by 
MPI_Type_create_struct in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:99:5: 
warning: ‘MPI_Address’ is deprecated (declared at 
../../ompi/include/mpi.h:1057): MPI_Address is superseded by 
MPI_Get_address in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:100:5: 
warning: ‘MPI_Address’ is deprecated (declared at 
../../ompi/include/mpi.h:1057): MPI_Address is superseded by 
MPI_Get_address in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:105:5: 
warning: ‘MPI_Type_struct’ is deprecated (declared at 
../../ompi/include/mpi.h:1579): MPI_Type_struct is superseded by 
MPI_Type_create_struct in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c: 
In function ‘create_indexed_gap_optimized_ddt’:
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:139:5: 
warning: ‘MPI_Type_struct’ is deprecated (declared at 
../../ompi/include/mpi.h:1579): MPI_Type_struct is superseded by 
MPI_Type_create_struct in MPI-2.0
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c: 
In function ‘do_test_for_ddt’:
/pub/devel/openmpi/openmpi-1.7rc7-1/src/openmpi-1.7rc7/test/datatype/to_self.c:307:5: 
warning: ‘MPI_Type_extent’ is deprecated (declared at 
../../ompi/include/mpi.h:1541): MPI_Type_extent is superseded by 
MPI_Type_get_extent in MPI-2.0

  CCLD to_self.exe


Is it expected ?
Or should the test updated to MPI-2.0 convention ?

Regards
Marco

Re: [OMPI devel] v1.7.0rc7

[marco atzeri]

On 2/23/2013 11:45 PM, Ralph Castain wrote:

This release candidate is the last one we expect to have before release, so 
please test it. Can be downloaded from the usual place:

http://www.open-mpi.org/software/ompi/v1.7/

Latest changes include:

* update of the alps/lustre configure code
* fixed solaris hwloc code
* various mxm updates
* removed java bindings (delayed until later release)
* improved the --report-bindings output
* a variety of minor cleanups



any reason to not include the cygwin patches added to 1.6.4 ?

Marco

Re: [OMPI devel] RFC: Remove windows support

[marco atzeri]

On 2/18/2013 5:10 PM, Jeff Squyres (jsquyres) wrote:

WHAT: Remove all Windows code from the trunk.

WHY: This issue keeps coming up over and over and over...


[cut]

2. Remove all Windows code.  This involves some wholesale removing of 
components as well as a bunch of #if code throughout the code base.

   ==> Removing this code can probably be done in multiple SVN commits:

2a. Removing Windows-only components (which, given the rate of change that we 
are planning for the trunk, may well need to be re-written if they are ever 
re-introduced into the tree).


Cygwin does not use them. I'm currently building the trunk packages with

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv,if-windows,shmem-windows

to specifically exclude them


2b. Removing "#if WINDOWS" code (e.g., in opal/util/*, etc.).  This code may 
not be changing as much as the rest of the trunk, and may be suitable for svn reverting 
someday.

This does kill Cygwin support, too.  I realize we have a downstream packager 
for Cygwin, but the fact that we can't get any developer support for Windows -- 
despite multiple appeals -- seems to imply that the Windows Open MPI audience 
is very, very small.  So while it feels a bit sad to kill it, it may still be 
the Right Thing to do.


I assume it is __WINDOWS__
That is not defined on cygwin, so the build should survive



This is a proposal, and is open for discussion.



Regards
Marco

[OMPI devel] openmpi-1.9a1r27710 on cygwin: patch and questions

[marco atzeri]

Hi,
additional to the patches used for building on cygwin
openmpi-1.7rc5, a new one is needed for openmpi-1.9a1r27710 build.
See attached for statfs usage.

As config parameters, I added "if-windows,shmem-windows"
to

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv,if-windows,shmem-windows


Question 1 :
instead of a platform check should be better to check
if statvfs or statfs are implemented on the platform ?

Question 2:
any specif reason to have reset the shared library
version numbers ?

On openmpi-1.9a1r27710
./usr/bin/cygmpi-0.dll
./usr/bin/cygmpi_cxx-0.dll
./usr/bin/cygmpi_mpifh-0.dll
./usr/bin/cygmpi_usempi-0.dll
./usr/bin/cygopen-pal-0.dll
./usr/bin/cygopen-rte-0.dll
./usr/lib/openmpi/cygompi_dbg_msgq.dll

On openmpi-1.7rc5
./usr/bin/cygmpi-1.dll
./usr/bin/cygmpi_cxx-1.dll
./usr/bin/cygmpi_mpifh-2.dll
./usr/bin/cygmpi_usempi-1.dll
./usr/bin/cygopen-pal-5.dll
./usr/bin/cygopen-rte-5.dll
./usr/lib/openmpi/cygompi_dbg_msgq.dll

Question 3:
 there is an alternative way to exclude all the "*-windows" mca
 instead of
--enable-mca-no-build=installdirs-windows,timer-windows,if-windows,shmem-windows


Regards
Marco
--- origsrc/openmpi-1.9a1r27710/opal/util/path.c2012-12-20 
03:00:25.0 +0100
+++ src/openmpi-1.9a1r27710/opal/util/path.c2012-12-21 14:34:15.432823000 
+0100
@@ -547,7 +547,7 @@
 #if defined(__SVR4) && defined(__sun)
 struct statvfs buf;
 #elif defined(__linux__) || defined (__BSD) || 
\
-  (defined(__APPLE__) && defined(__MACH__))
+  (defined(__APPLE__) && defined(__MACH__)) || defined(__CYGWIN__)
 struct statfs buf;
 #endif

@@ -560,7 +560,7 @@
 #if defined(__SVR4) && defined(__sun)
 rc = statvfs(path, );
 #elif defined(__linux__) || defined (__BSD) || 
\
-  (defined(__APPLE__) && defined(__MACH__))
+  (defined(__APPLE__) && defined(__MACH__)) || defined(__CYGWIN__)
 rc = statfs(path, );
 #endif
 err = errno;

Re: [OMPI devel] openmpi-1.7rc5 on cygwin ; results and patches

[marco atzeri]

On 12/20/2012 1:59 PM, Jeff Squyres wrote:

Thank you!  I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about 
this.

Do you have any Open MPI v1.6-specific patches that would be useful to merge 
upstream?  I've looked through my email and don't see any, but I could be 
missing them.




Hi Jeff,
these 3 are the one used on 1.6.x


  path_null.patch : https://svn.open-mpi.org/trac/ompi/ticket/3371
  SHM.patch   : posix alternative at  "SHM_R | SHM_W"
  cygwin-dlname.patch : cygwin specific for .dll instead of .so suffix



path_null.patch is already in

SHM.patchis generic enough that should work on any platform.
  Please check

cygwin-dlname.patch   as written is windows only.
   It needs a configuration check for choosing the
   right shared library suffix for the platform


Marco

[OMPI devel] openmpi-1.7rc5 on cygwin ; results and patches

[marco atzeri]

Built and tested openmpi-1.7rc5 on cygwin, same configuration
than 1.6.3-4 package

./autogen.sh
configure \
LDFLAGS="-Wl,--export-all-symbols -no-undefined"  \
--disable-mca-dso \
--disable-sysv-shmem \
--without-udapl \
--enable-cxx-exceptions \
--with-threads=posix \
--without-cs-fs \
--enable-heterogeneous \
--with-mpi-param_check=always \
--enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv


In addition to the previous 3 patches:
  path_null.patch : https://svn.open-mpi.org/trac/ompi/ticket/3371
  SHM.patch   : posix alternative at  "SHM_R | SHM_W"
  cygwin-dlname.patch : cygwin specific for .dll instead of .so suffix

I needed additional patches:
  ERROR.patch : ERROR is already defined, so another label
is needed for "goto ERROR"
  interface.patch : same for interface , it seems a
struct somewhere else
  min.patch   : min already defined as macro
(I saw in the source also a MIN macro defined)
  mpifh.patch : to avoid undefined error
libmpi_mpifh_la_LIBADD needs
$(top_builddir)/ompi/libmpi.la
  winsock.patch   : defense against  usage


Full package here :
http://matzeri.altervista.org/cygwin-1.7/openmpi/

Osu-micro-benchmarks-3.7 results here :
http://matzeri.altervista.org/works/ompi/

Regards
Marco
--- origsrc/openmpi-1.6.3/ompi/debuggers/Makefile.am2012-04-03 
09:30:25.0 -0500
+++ src/openmpi-1.6.3/ompi/debuggers/Makefile.am2012-11-15 
19:52:47.037390400 -0600
@@ -58,9 +58,9 @@ libdebuggers_la_SOURCES = \
 $(headers) \
 ompi_debuggers.c
 libdebuggers_la_CPPFLAGS = \
--DOMPI_MSGQ_DLL=\"$(pkglibdir)/libompi_dbg_msgq.so\" \
--DOMPI_MSGQ_DLL_PREFIX=\"libompi_dbg_msgq\" \
--DOMPI_MPIHANDLES_DLL_PREFIX=\"libompi_dbg_mpihandles\"
+-DOMPI_MSGQ_DLL=\"$(pkglibdir)/cygompi_dbg_msgq.dll\" \
+-DOMPI_MSGQ_DLL_PREFIX=\"cygompi_dbg_msgq\" \
+-DOMPI_MPIHANDLES_DLL_PREFIX=\"cygompi_dbg_mpihandles\"

 libompi_debugger_canary_la_SOURCES = \
 ompi_debugger_canary.c
--- orig/openmpi-1.7rc5/ompi/mca/bcol/basesmuma/bcol_basesmuma_buf_mgmt.c   
2012-10-05 13:13:34.0 +0200
+++ openmpi-1.7rc5/ompi/mca/bcol/basesmuma/bcol_basesmuma_buf_mgmt.c
2012-12-19 11:18:55.123709300 +0100
@@ -213,7 +213,7 @@
pload_mgmt->data_buffs = malloc(malloc_size);
if( !pload_mgmt->data_buffs) {
ret = OMPI_ERR_OUT_OF_RESOURCE;
-   goto ERROR;
+   goto exit_ERROR;
}

/* setup the input file for the shared memory connection manager */
@@ -234,7 +234,7 @@
input_file,
false);
if( OMPI_SUCCESS != ret ) {
-   goto ERROR;
+   goto exit_ERROR;
}

/* now we exchange offset info - don't assume symmetric virtual memory
@@ -247,7 +247,7 @@
   (void **)pload_mgmt->data_buffs, mem_offset, 0,
   pload_mgmt->size_of_group);
if( OMPI_SUCCESS != ret ) {
-   goto ERROR;
+   goto exit_ERROR;
}

/* convert memory offset to virtual address in current rank */
@@ -285,7 +285,7 @@

 return OMPI_SUCCESS;

-ERROR:
+exit_ERROR:
 return ret;
 }
 #endif
@@ -387,7 +387,7 @@
pload_mgmt->data_buffs = (mca_bcol_basesmuma_payload_t *) 
malloc(malloc_size);
if( !pload_mgmt->data_buffs) {
ret = OMPI_ERR_OUT_OF_RESOURCE;
-   goto ERROR;
+   goto exit_ERROR;
}

 /* allocate some memory to hold the offsets */
@@ -411,7 +411,7 @@
input_file,cs->payload_base_fname,
false);
if( OMPI_SUCCESS != ret ) {
-   goto ERROR;
+   goto exit_ERROR;
}


@@ -429,7 +429,7 @@
 sm_bcol_module->super.sbgp_partner_module->group_list,
 sm_bcol_module->super.sbgp_partner_module->group_comm);
 if( OMPI_SUCCESS != ret ) {
-goto ERROR;
+goto exit_ERROR;
 }

/* convert memory offset to virtual address in current rank */
@@ -525,7 +525,7 @@

return OMPI_SUCCESS;

-ERROR:
+exit_ERROR:
return ret;
 }

--- orig/openmpi-1.7rc5/ompi/mca/bcol/basesmuma/bcol_basesmuma_component.c  
2012-10-25 02:56:21.0 +0200
+++ openmpi-1.7rc5/ompi/mca/bcol/basesmuma/bcol_basesmuma_component.c   
2012-12-19 11:19:45.037772500 +0100
@@ -142,7 +142,7 @@
 roundup_to_power_radix(2,cs->basesmuma_num_mem_banks, );
 if ( 0 == cs->basesmuma_num_mem_banks ) {
 ret=OMPI_ERROR;
-