June 2014 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] what version of patch is required for autogen.sh?
by "Antonio J. Peña" 24 Jun '14

24 Jun '14

--forward is the long equivalent to -N. I'm using GNU patch 2.7.1. I'll change --forward to -N. Toni On 06/24/2014 06:13 PM, Jeff Hammond wrote: > What version of patch do I need for the following errors to disappear? > > Thanks, > > jeff > > Patching libtool.m4 to enable support for powerpcle... patch: > unrecognized option `--forward' > BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary > > Usage: patch [-p NUM] [-i DIFF] [-R] [-N] > > -p NUM Strip NUM leading components from file names > -i DIFF Read DIFF instead of stdin > -R Reverse patch > -N Ignore already applied patches > > failed > Patching libtool.m4 for compatibility with nagfor shared libraries... > patch: unrecognized option `--forward' > BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary > > Usage: patch [-p NUM] [-i DIFF] [-R] [-N] > > -p NUM Strip NUM leading components from file names > -i DIFF Read DIFF instead of stdin > -R Reverse patch > -N Ignore already applied patches > > failed > ------------------------------------------------------------------------ > running autoreconf in src/mpl > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `confdb'. > libtoolize: copying file `confdb/ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `confdb'. > libtoolize: copying file `confdb/libtool.m4' > libtoolize: copying file `confdb/ltoptions.m4' > libtoolize: copying file `confdb/ltsugar.m4' > libtoolize: copying file `confdb/ltversion.m4' > libtoolize: copying file `confdb/lt~obsolete.m4' > Patching libtool.m4 to enable support for powerpcle... patch: > unrecognized option `--forward' > BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary > > Usage: patch [-p NUM] [-i DIFF] [-R] [-N] > > -p NUM Strip NUM leading components from file names > -i DIFF Read DIFF instead of stdin > -R Reverse patch > -N Ignore already applied patches > > failed > Patching libtool.m4 for compatibility with nagfor shared libraries... > patch: unrecognized option `--forward' > BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary > > Usage: patch [-p NUM] [-i DIFF] [-R] [-N] > > -p NUM Strip NUM leading components from file names > -i DIFF Read DIFF instead of stdin > -R Reverse patch > -N Ignore already applied patches > > failed > ------------------------------------------------------------------------ > running autoreconf in src/util/logging/rlog > -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

what version of patch is required for autogen.sh?
by Jeff Hammond 24 Jun '14

24 Jun '14

What version of patch do I need for the following errors to disappear? Thanks, jeff Patching libtool.m4 to enable support for powerpcle... patch: unrecognized option `--forward' BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary Usage: patch [-p NUM] [-i DIFF] [-R] [-N] -p NUM Strip NUM leading components from file names -i DIFF Read DIFF instead of stdin -R Reverse patch -N Ignore already applied patches failed Patching libtool.m4 for compatibility with nagfor shared libraries... patch: unrecognized option `--forward' BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary Usage: patch [-p NUM] [-i DIFF] [-R] [-N] -p NUM Strip NUM leading components from file names -i DIFF Read DIFF instead of stdin -R Reverse patch -N Ignore already applied patches failed ------------------------------------------------------------------------ running autoreconf in src/mpl libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `confdb'. libtoolize: copying file `confdb/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `confdb'. libtoolize: copying file `confdb/libtool.m4' libtoolize: copying file `confdb/ltoptions.m4' libtoolize: copying file `confdb/ltsugar.m4' libtoolize: copying file `confdb/ltversion.m4' libtoolize: copying file `confdb/lt~obsolete.m4' Patching libtool.m4 to enable support for powerpcle... patch: unrecognized option `--forward' BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary Usage: patch [-p NUM] [-i DIFF] [-R] [-N] -p NUM Strip NUM leading components from file names -i DIFF Read DIFF instead of stdin -R Reverse patch -N Ignore already applied patches failed Patching libtool.m4 for compatibility with nagfor shared libraries... patch: unrecognized option `--forward' BusyBox v1.15.1 (2012-06-21 22:59:00 CDT) multi-call binary Usage: patch [-p NUM] [-i DIFF] [-R] [-N] -p NUM Strip NUM leading components from file names -i DIFF Read DIFF instead of stdin -R Reverse patch -N Ignore already applied patches failed ------------------------------------------------------------------------ running autoreconf in src/util/logging/rlog -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] MIC configure fails: cannot find input file: `src/binding/f90/mpif90model.h.in'
by Jeff Hammond 24 Jun '14

24 Jun '14

Okay, I'm stupid and forget to autogen.sh. Some day maybe configure will help me out in this regard... Jeff On Tue, Jun 24, 2014 at 3:09 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I am using NERSC Babbage. > > $ ../configure --prefix=/global/homes/j/jhammond/MPI/install-mpich-mic > --host=x86_64-k1om-linux CC=icc CXX=icpc CFLAGS=-mmic CPPFLAGS=-mmic > CXXFLAGS=-mmic FC=ifort F77=ifort FCFLAGS=-mmic FFLAGS=-mmic > --with-cross=../src/mpid/ch3/channels/nemesis/netmod/scif/cross_values.txt > --with-device=ch3:nemesis:scif --disable-shared > > The tail of the output (complete output attached) is: > > configure: WARNING: The ch3:nemesis:scif device did not set the > maximum size of an error string, 512 being used. > configure: creating ./config.lt > config.lt: creating libtool > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: error: cannot find input file: `src/binding/f90/mpif90model.h.in' > > My attempts to configure without Fortran support failed, otherwise I'd > not try to use it. > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

MIC configure fails: cannot find input file: `src/binding/f90/mpif90model.h.in'
by Jeff Hammond 24 Jun '14

24 Jun '14

I am using NERSC Babbage. $ ../configure --prefix=/global/homes/j/jhammond/MPI/install-mpich-mic --host=x86_64-k1om-linux CC=icc CXX=icpc CFLAGS=-mmic CPPFLAGS=-mmic CXXFLAGS=-mmic FC=ifort F77=ifort FCFLAGS=-mmic FFLAGS=-mmic --with-cross=../src/mpid/ch3/channels/nemesis/netmod/scif/cross_values.txt --with-device=ch3:nemesis:scif --disable-shared The tail of the output (complete output attached) is: configure: WARNING: The ch3:nemesis:scif device did not set the maximum size of an error string, 512 being used. configure: creating ./config.lt config.lt: creating libtool checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `src/binding/f90/mpif90model.h.in' My attempts to configure without Fortran support failed, otherwise I'd not try to use it. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] win_shared_noncontig test
by Kenneth Raffenetti 17 Jun '14

17 Jun '14

Thanks for the heads-up, Dave. We just pushed a fix for those tests. Ken On 06/16/2014 05:55 PM, Dave Goodell (dgoodell) wrote: > This OMPI bug may be of note to the MPICH community: https://svn.open-mpi.org/trac/ompi/ticket/4721 > > -Dave > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] win_shared_noncontig test
by Jeff Hammond 17 Jun '14

17 Jun '14

On Tue, Jun 17, 2014 at 3:51 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > > > On 17 June 2014 01:55, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: >> >> This OMPI bug may be of note to the MPICH community: >> https://svn.open-mpi.org/trac/ompi/ticket/4721 >> > > From a user point of view, I do not like that behaviour. I agree that the > MPI implementation is free to allocate as much space it is convenient, but > the size it reports back after a query is a different story. Does the MPI > standard requires that the result query of the query is the exact allocated > size? If not, I see more convenient to return the requested-at-allocation- > time size the the allocated one. What's the use case of returning the exact > allocated size? After all, I guess users cannot rely on "extra space" being > available at the end of the buffer. http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf page 410 explicitly permits padding in the case of alloc_shared_noncontig=True. The user can use exactly the amount in the window, which is either the exact amount they requested or a slightly larger amount due to padding. What is wrong with that? I think it is a very good idea to let users know how much memory is being allocated, because this might cause them to improve their usage of MPI. For example, someone might think its a good idea to have a C++ flag object in shared memory and allocate an 8-byte shared-memory window in each object constructor. They might think alloc_shared_noncontig=True is an optimization, but the OS could decide to round up to the page boundary. Thus, the users lightweight flag object is allocating 4096+n bytes instead of 8+n, where n is the number of bytes in the object but not the window. Exposing this tidbit to the user might inspire them to allocate a pool for shared-memory flag state that doesn't waste memory. I suppose you could complain about the implementation rounding up to page boundaries, but this might be required by the OS, in which case you'll have to complain to someone like Linus about it :-D The MPI standard occasionally exposes low-level information to users that is not necessarily helpful. It is quite straightforward to implement a library on top of MPI that hides this information if it is considered detrimental to user experience. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] win_shared_noncontig test
by Lisandro Dalcin 17 Jun '14

17 Jun '14

On 17 June 2014 01:55, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > This OMPI bug may be of note to the MPICH community: > https://svn.open-mpi.org/trac/ompi/ticket/4721 > > From a user point of view, I do not like that behaviour. I agree that the MPI implementation is free to allocate as much space it is convenient, but the size it reports back after a query is a different story. Does the MPI standard requires that the result query of the query is the exact allocated size? If not, I see more convenient to return the requested-at-allocation- time size the the allocated one. What's the use case of returning the exact allocated size? After all, I guess users cannot rely on "extra space" being available at the end of the buffer. -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

win_shared_noncontig test
by Dave Goodell (dgoodell) 16 Jun '14

16 Jun '14

This OMPI bug may be of note to the MPICH community: https://svn.open-mpi.org/trac/ompi/ticket/4721 -Dave

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1.1-8-gbe93cae
by Dave Goodell (dgoodell) 11 Jun '14

11 Jun '14

[accidentally responded to moderated commits@, not devel@] On Jun 11, 2014, at 2:05 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On Jun 11, 2014, at 11:01 AM, Service Account <noreply(a)mpich.org> wrote: > >> commit be93caec6c6b9b230fbde9b1b296cde001fde934 >> Author: Antonio J. Pena <apenya(a)mcs.anl.gov> >> Date: Mon Jun 9 17:12:17 2014 -0500 >> >> Added support for thread-safe errno in Solaris >> >> The _REENTRANT macro is required to be defined in order to get >> thread-safe "errno" values. Modern POSIX systems provide this by default >> when using -lpthreads, but there are still some (Solaris) that require >> an explicit define. Since we weren't compiling with that macro, we were >> getting incorrect "errno" values from the threads (mainly 0). >> >> More details: since we use nonblocking sockets, our code was checking >> "errno" to not be EINPROGRESS whenever we got an error code from a >> connect/accept, in order to determine an actual error (a return value >> of -1 and errno of EINPROGRESS does not define an actual error but a >> "not yet" when using nonblocking sockets). > > Interesting, I did not know about this Solaris "quirk". > >> This patch automatically gets this macro defined by configure whenever >> we are not building in MPI_THREAD_SINGLE mode only. >> >> Fixes #2107 >> >> Signed-off-by: Ken Raffenetti <raffenet(a)mcs.anl.gov> >> >> diff --git a/configure.ac b/configure.ac >> index 936f6ce..96545b0 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -1352,6 +1352,13 @@ fi >> export MPICH_THREAD_LEVEL >> AC_DEFINE_UNQUOTED(MPICH_THREAD_LEVEL,$MPICH_THREAD_LEVEL,[Level of thread support selected at compile time]) >> >> +# If not in MPI_THREAD_SINGLE, we need -D_REENTRANT to get thread-safe "errno". >> +# Most POSIX systems provide this by default when using -lpthread, but we only use it in MPI_THREAD_MULTIPLE. >> +# Some systems (Solaris) still require an explicit define in any case. >> +if test "$MPICH_THREAD_LEVEL" != "MPI_THREAD_SINGLE"; then >> + PAC_APPEND_FLAG([-D_REENTRANT], [CFLAGS]) > > A largely academic observation, but: should this be CPPFLAGS instead? > > -Dave >

1 0

Re: [mpich-devel] visual studio finally supports all c99 ?
by Jeff Hammond 10 Jun '14

10 Jun '14

I think Jed said on G+ that they don't have full C99 yet, but given that MPICH hasn't supported Windows in a long time, I do not see why MSVC is remotely relevant to MPICH decisions. And one can use Intel compilers on Windows if one wants a serious C compiler there. Jeff Sent from my iPhone > On Jun 10, 2014, at 9:21 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > > http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring… > > what else is holding up adoption of c99 ? > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0