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

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Hal Finkel 30 Jun '14

30 Jun '14

----- Original Message ----- > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > To: "Hal Finkel" <hfinkel(a)anl.gov> > Cc: "Pavan Balaji" <balaji(a)anl.gov>, devel(a)mpich.org > Sent: Monday, June 30, 2014 3:59:50 PM > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Hi Hal, > > The functions of poking progress engine are MPID_Progress_poke(), > MPID_Progress_wait() and MPID_Progress_test(), but they are not > provided with a request pointer directly. > By saying "pass the single request pointer", I mean we pass it when > issuing operations (location I mentioned in the last email), and if > it is not completed, the request will be enqueued in a queue in the > lower layer. When we call MPID_Progress_ functions, the progress > engine will process on that queue and try to make more requests > completed. Thanks, now I understand what you meant. -Hal > > Xin > ________________________________________ > From: Hal Finkel [hfinkel(a)anl.gov] > Sent: Monday, June 30, 2014 3:45 PM > To: Zhao, Xin > Cc: Pavan Balaji; devel(a)mpich.org > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > ----- Original Message ----- > > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > > To: "Hal Finkel" <hfinkel(a)anl.gov> > > Cc: "Pavan Balaji" <balaji(a)anl.gov>, devel(a)mpich.org > > Sent: Monday, June 30, 2014 3:39:20 PM > > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > Hi Hal, > > > > I am not sure if I understand you correctly. If you mean the > > function > > that CH3 uses to pass the message to the lower layer, it indeed > > tests if it is completed or not upon return from nemesis. If > > completed, CH3 will free that operation immediately, if not, it > > will > > leave that operation in the list. You can refer to L1087~L1097 in > > src/mpid/ch3/src/ch3u_rma_sync.c in latest mpich/master about this. > > No, I mean where is the code in the CH3 layer that calls the nemesis > layer (pokes the progress engine?) providing it only with the single > request pointer? In short, where is this "We didn't pass the list to > the nemesis layer but only pass the single request pointer"? > > Thanks again, > Hal > > > > > Xin > > ________________________________________ > > From: Hal Finkel [hfinkel(a)anl.gov] > > Sent: Monday, June 30, 2014 3:07 PM > > To: Zhao, Xin > > Cc: Pavan Balaji; devel(a)mpich.org > > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > ----- Original Message ----- > > > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > > > To: "Hal Finkel" <hfinkel(a)anl.gov>, devel(a)mpich.org > > > Cc: "Pavan Balaji" <balaji(a)anl.gov> > > > Sent: Monday, June 30, 2014 2:14:15 PM > > > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > > > Hi Hal, > > > > > > Currently the RMA operation list is implemented in CH3 layer, > > > whereas > > > the progress engine is implemented in nemesis layer. We didn't > > > pass > > > the list to the nemesis layer but only pass the single request > > > pointer, so the progress engine now only modify on the request > > > pointer. > > > > Thanks for the explanation. FWIW, I don't understand why the > > calling > > code (in CH3) could not test for complete upon return from nemesis > > and handle it then. Which function handles this? > > > > -Hal > > > > > This is one of the problems we have with the current > > > separation of the CH3 and nemesis layers, we plan to merge these > > > layers in future and this should be fixed at that time. > > > > > > Thanks, > > > Xin > > > ________________________________________ > > > From: Hal Finkel [hfinkel(a)anl.gov] > > > Sent: Monday, June 30, 2014 1:28 PM > > > To: devel(a)mpich.org > > > Cc: Zhao, Xin; Pavan Balaji > > > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > > > Xin, et al., > > > > > > Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added > > > MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a > > > request > > > is completed by the progress engine, why can't the progress > > > engine > > > move it to the beginning of the list (or the end), and have > > > rma_list_gc only search from the beginning (or end) until it > > > finds > > > an incomplete request? > > > > > > Thanks in advance, > > > Hal > > > > > > -- > > > Hal Finkel > > > Assistant Computational Scientist > > > Leadership Computing Facility > > > Argonne National Laboratory > > > > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Zhao, Xin 30 Jun '14

30 Jun '14

Hi Hal, The functions of poking progress engine are MPID_Progress_poke(), MPID_Progress_wait() and MPID_Progress_test(), but they are not provided with a request pointer directly. By saying "pass the single request pointer", I mean we pass it when issuing operations (location I mentioned in the last email), and if it is not completed, the request will be enqueued in a queue in the lower layer. When we call MPID_Progress_ functions, the progress engine will process on that queue and try to make more requests completed. Xin ________________________________________ From: Hal Finkel [hfinkel(a)anl.gov] Sent: Monday, June 30, 2014 3:45 PM To: Zhao, Xin Cc: Pavan Balaji; devel(a)mpich.org Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED ----- Original Message ----- > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > To: "Hal Finkel" <hfinkel(a)anl.gov> > Cc: "Pavan Balaji" <balaji(a)anl.gov>, devel(a)mpich.org > Sent: Monday, June 30, 2014 3:39:20 PM > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Hi Hal, > > I am not sure if I understand you correctly. If you mean the function > that CH3 uses to pass the message to the lower layer, it indeed > tests if it is completed or not upon return from nemesis. If > completed, CH3 will free that operation immediately, if not, it will > leave that operation in the list. You can refer to L1087~L1097 in > src/mpid/ch3/src/ch3u_rma_sync.c in latest mpich/master about this. No, I mean where is the code in the CH3 layer that calls the nemesis layer (pokes the progress engine?) providing it only with the single request pointer? In short, where is this "We didn't pass the list to the nemesis layer but only pass the single request pointer"? Thanks again, Hal > > Xin > ________________________________________ > From: Hal Finkel [hfinkel(a)anl.gov] > Sent: Monday, June 30, 2014 3:07 PM > To: Zhao, Xin > Cc: Pavan Balaji; devel(a)mpich.org > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > ----- Original Message ----- > > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > > To: "Hal Finkel" <hfinkel(a)anl.gov>, devel(a)mpich.org > > Cc: "Pavan Balaji" <balaji(a)anl.gov> > > Sent: Monday, June 30, 2014 2:14:15 PM > > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > Hi Hal, > > > > Currently the RMA operation list is implemented in CH3 layer, > > whereas > > the progress engine is implemented in nemesis layer. We didn't pass > > the list to the nemesis layer but only pass the single request > > pointer, so the progress engine now only modify on the request > > pointer. > > Thanks for the explanation. FWIW, I don't understand why the calling > code (in CH3) could not test for complete upon return from nemesis > and handle it then. Which function handles this? > > -Hal > > > This is one of the problems we have with the current > > separation of the CH3 and nemesis layers, we plan to merge these > > layers in future and this should be fixed at that time. > > > > Thanks, > > Xin > > ________________________________________ > > From: Hal Finkel [hfinkel(a)anl.gov] > > Sent: Monday, June 30, 2014 1:28 PM > > To: devel(a)mpich.org > > Cc: Zhao, Xin; Pavan Balaji > > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > Xin, et al., > > > > Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added > > MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request > > is completed by the progress engine, why can't the progress engine > > move it to the beginning of the list (or the end), and have > > rma_list_gc only search from the beginning (or end) until it finds > > an incomplete request? > > > > Thanks in advance, > > Hal > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Hal Finkel 30 Jun '14

30 Jun '14

----- Original Message ----- > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > To: "Hal Finkel" <hfinkel(a)anl.gov> > Cc: "Pavan Balaji" <balaji(a)anl.gov>, devel(a)mpich.org > Sent: Monday, June 30, 2014 3:39:20 PM > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Hi Hal, > > I am not sure if I understand you correctly. If you mean the function > that CH3 uses to pass the message to the lower layer, it indeed > tests if it is completed or not upon return from nemesis. If > completed, CH3 will free that operation immediately, if not, it will > leave that operation in the list. You can refer to L1087~L1097 in > src/mpid/ch3/src/ch3u_rma_sync.c in latest mpich/master about this. No, I mean where is the code in the CH3 layer that calls the nemesis layer (pokes the progress engine?) providing it only with the single request pointer? In short, where is this "We didn't pass the list to the nemesis layer but only pass the single request pointer"? Thanks again, Hal > > Xin > ________________________________________ > From: Hal Finkel [hfinkel(a)anl.gov] > Sent: Monday, June 30, 2014 3:07 PM > To: Zhao, Xin > Cc: Pavan Balaji; devel(a)mpich.org > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > ----- Original Message ----- > > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > > To: "Hal Finkel" <hfinkel(a)anl.gov>, devel(a)mpich.org > > Cc: "Pavan Balaji" <balaji(a)anl.gov> > > Sent: Monday, June 30, 2014 2:14:15 PM > > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > Hi Hal, > > > > Currently the RMA operation list is implemented in CH3 layer, > > whereas > > the progress engine is implemented in nemesis layer. We didn't pass > > the list to the nemesis layer but only pass the single request > > pointer, so the progress engine now only modify on the request > > pointer. > > Thanks for the explanation. FWIW, I don't understand why the calling > code (in CH3) could not test for complete upon return from nemesis > and handle it then. Which function handles this? > > -Hal > > > This is one of the problems we have with the current > > separation of the CH3 and nemesis layers, we plan to merge these > > layers in future and this should be fixed at that time. > > > > Thanks, > > Xin > > ________________________________________ > > From: Hal Finkel [hfinkel(a)anl.gov] > > Sent: Monday, June 30, 2014 1:28 PM > > To: devel(a)mpich.org > > Cc: Zhao, Xin; Pavan Balaji > > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > > > Xin, et al., > > > > Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added > > MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request > > is completed by the progress engine, why can't the progress engine > > move it to the beginning of the list (or the end), and have > > rma_list_gc only search from the beginning (or end) until it finds > > an incomplete request? > > > > Thanks in advance, > > Hal > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Zhao, Xin 30 Jun '14

30 Jun '14

Hi Hal, I am not sure if I understand you correctly. If you mean the function that CH3 uses to pass the message to the lower layer, it indeed tests if it is completed or not upon return from nemesis. If completed, CH3 will free that operation immediately, if not, it will leave that operation in the list. You can refer to L1087~L1097 in src/mpid/ch3/src/ch3u_rma_sync.c in latest mpich/master about this. Xin ________________________________________ From: Hal Finkel [hfinkel(a)anl.gov] Sent: Monday, June 30, 2014 3:07 PM To: Zhao, Xin Cc: Pavan Balaji; devel(a)mpich.org Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED ----- Original Message ----- > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > To: "Hal Finkel" <hfinkel(a)anl.gov>, devel(a)mpich.org > Cc: "Pavan Balaji" <balaji(a)anl.gov> > Sent: Monday, June 30, 2014 2:14:15 PM > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Hi Hal, > > Currently the RMA operation list is implemented in CH3 layer, whereas > the progress engine is implemented in nemesis layer. We didn't pass > the list to the nemesis layer but only pass the single request > pointer, so the progress engine now only modify on the request > pointer. Thanks for the explanation. FWIW, I don't understand why the calling code (in CH3) could not test for complete upon return from nemesis and handle it then. Which function handles this? -Hal > This is one of the problems we have with the current > separation of the CH3 and nemesis layers, we plan to merge these > layers in future and this should be fixed at that time. > > Thanks, > Xin > ________________________________________ > From: Hal Finkel [hfinkel(a)anl.gov] > Sent: Monday, June 30, 2014 1:28 PM > To: devel(a)mpich.org > Cc: Zhao, Xin; Pavan Balaji > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Xin, et al., > > Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added > MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request > is completed by the progress engine, why can't the progress engine > move it to the beginning of the list (or the end), and have > rma_list_gc only search from the beginning (or end) until it finds > an incomplete request? > > Thanks in advance, > Hal > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Hal Finkel 30 Jun '14

30 Jun '14

----- Original Message ----- > From: "Xin Zhao" <xinzhao3(a)illinois.edu> > To: "Hal Finkel" <hfinkel(a)anl.gov>, devel(a)mpich.org > Cc: "Pavan Balaji" <balaji(a)anl.gov> > Sent: Monday, June 30, 2014 2:14:15 PM > Subject: RE: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Hi Hal, > > Currently the RMA operation list is implemented in CH3 layer, whereas > the progress engine is implemented in nemesis layer. We didn't pass > the list to the nemesis layer but only pass the single request > pointer, so the progress engine now only modify on the request > pointer. Thanks for the explanation. FWIW, I don't understand why the calling code (in CH3) could not test for complete upon return from nemesis and handle it then. Which function handles this? -Hal > This is one of the problems we have with the current > separation of the CH3 and nemesis layers, we plan to merge these > layers in future and this should be fixed at that time. > > Thanks, > Xin > ________________________________________ > From: Hal Finkel [hfinkel(a)anl.gov] > Sent: Monday, June 30, 2014 1:28 PM > To: devel(a)mpich.org > Cc: Zhao, Xin; Pavan Balaji > Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED > > Xin, et al., > > Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added > MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request > is completed by the progress engine, why can't the progress engine > move it to the beginning of the list (or the end), and have > rma_list_gc only search from the beginning (or end) until it finds > an incomplete request? > > Thanks in advance, > Hal > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Zhao, Xin 30 Jun '14

30 Jun '14

Hi Hal, Currently the RMA operation list is implemented in CH3 layer, whereas the progress engine is implemented in nemesis layer. We didn't pass the list to the nemesis layer but only pass the single request pointer, so the progress engine now only modify on the request pointer. This is one of the problems we have with the current separation of the CH3 and nemesis layers, we plan to merge these layers in future and this should be fixed at that time. Thanks, Xin ________________________________________ From: Hal Finkel [hfinkel(a)anl.gov] Sent: Monday, June 30, 2014 1:28 PM To: devel(a)mpich.org Cc: Zhao, Xin; Pavan Balaji Subject: Re: MPIR_CVAR_CH3_RMA_GC_NUM_TESTED Xin, et al., Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request is completed by the progress engine, why can't the progress engine move it to the beginning of the list (or the end), and have rma_list_gc only search from the beginning (or end) until it finds an incomplete request? Thanks in advance, Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] MPIR_CVAR_CH3_RMA_GC_NUM_TESTED
by Hal Finkel 30 Jun '14

30 Jun '14

Xin, et al., Regarding 283319f5d9d1cdbcf016dc0ff8ab284114c0be7e (which added MPIR_CVAR_CH3_RMA_GC_NUM_TESTED and associated code): If a request is completed by the progress engine, why can't the progress engine move it to the beginning of the list (or the end), and have rma_list_gc only search from the beginning (or end) until it finds an incomplete request? Thanks in advance, Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

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

24 Jun '14

This should be fixed now in MPICH's master. 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

Re: [mpich-devel] what version of patch is required for autogen.sh?
by Jeff Hammond 24 Jun '14

24 Jun '14

I was surprised to see that too, particularly since I thought I was using a "real computer" - https://www.nersc.gov/users/computational-systems/testbeds/babbage/. I'm sure NERSC has a reason for providing me BusyBox but I don't know what it is. In any case, I am giving up on building the git master and switching to the 3.1.1 release tarball. If for some reason that isn't new enough, I'll use the nightly tarball. Jeff On Tue, Jun 24, 2014 at 4:17 PM, Larry Baker <baker(a)usgs.gov> wrote: > Jeff, > > You know you are not really using "patch", but the dumbed-down > patch-compatible BusyBox command? If you have real "patch" on your system, > maybe all you have to do is alter your PATH so it gets used instead of > BusyBox's patch. Otherwise, like this is for an embedded system, you might > have to cross-compile/build from an environment with grown-up versions of > the development tools. > > Larry Baker > US Geological Survey > 650-329-5608 > baker(a)usgs.gov > > > > On 24 Jun 2014, at 4: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 > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] what version of patch is required for autogen.sh?
by Larry Baker 24 Jun '14

24 Jun '14

Jeff, You know you are not really using "patch", but the dumbed-down patch-compatible BusyBox command? If you have real "patch" on your system, maybe all you have to do is alter your PATH so it gets used instead of BusyBox's patch. Otherwise, like this is for an embedded system, you might have to cross-compile/build from an environment with grown-up versions of the development tools. Larry Baker US Geological Survey 650-329-5608 baker(a)usgs.gov On 24 Jun 2014, at 4: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 > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0