- devel - mailman3.cels.anl.gov

Re: [mpich-devel] Mac autogen.sh fails
by Bland, Wesley 08 Dec '17

08 Dec '17

Ugh. I can confirm that this is happening and it only seems to be in master. The v3.2.1 tag doesn't have this problem. This must have come from all of our messing with the autogen.sh script. On Dec 7, 2017, at 3:51 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: autogen.sh is failing for me on Mac because Apple's libtool is not in the same place as Homebrew's autoconf/automake. I perused autogen.sh but didn't see an option to fix this. I need to use Homebrew autotools for other projects and don't want to uninstall Xcode for obvious reasons. Is there a workaround besides hacking autogen.sh and hating myself? I'd like to cause it to glibtool instead. If nothing else, autogen.sh incorrectly prints the location of libtool. It is in /usr/bin not /. Thanks, Jeff jrhammon-mac01:git jrhammon$ which libtool /usr/bin/libtool jrhammon-mac01:git jrhammon$ which autoconf /usr/local/bin/autoconf jrhammon-mac01:git jrhammon$ which automake /usr/local/bin/automake jrhammon-mac01:git jrhammon$ which glibtool /usr/local/bin/glibtool jrhammon-mac01:git jrhammon$ ./autogen.sh #################################### ## Checking user environment #################################### Verifying the location of autogen.sh... done usage: dirname path Checking if autotools are in the same location... no autoconf is in /usr/local automake is in /usr/local libtool is in / ===> WARNING: Autotools are in different locations. In rare occasion, ===> WARNING: resulting configure or makefile may fail in some unexpected ways. Checking if autoreconf accepts -I //share/aclocal... no Checking if autoreconf works after an additional libtoolize step... no ===> ERROR: Since none of the autoreconf workaround works ===> ERROR: and autotools are not in the same directory, aborting... ===> ERROR: Updating autotools or putting all autotools in the same location ===> ERROR: may resolve the issue. -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel

1 0

Mac autogen.sh fails
by Jeff Hammond 07 Dec '17

07 Dec '17

autogen.sh is failing for me on Mac because Apple's libtool is not in the same place as Homebrew's autoconf/automake. I perused autogen.sh but didn't see an option to fix this. I need to use Homebrew autotools for other projects and don't want to uninstall Xcode for obvious reasons. Is there a workaround besides hacking autogen.sh and hating myself? I'd like to cause it to glibtool instead. If nothing else, autogen.sh incorrectly prints the location of libtool. It is in /usr/bin not /. Thanks, Jeff jrhammon-mac01:git jrhammon$ which libtool /usr/bin/libtool jrhammon-mac01:git jrhammon$ which autoconf /usr/local/bin/autoconf jrhammon-mac01:git jrhammon$ which automake /usr/local/bin/automake jrhammon-mac01:git jrhammon$ which glibtool /usr/local/bin/glibtool jrhammon-mac01:git jrhammon$ ./autogen.sh #################################### ## Checking user environment #################################### Verifying the location of autogen.sh... done usage: dirname path Checking if autotools are in the same location... no autoconf is in /usr/local automake is in /usr/local libtool is in / ===> WARNING: Autotools are in different locations. In rare occasion, ===> WARNING: resulting configure or makefile may fail in some unexpected ways. Checking if autoreconf accepts -I //share/aclocal... no Checking if autoreconf works after an additional libtoolize step... no ===> ERROR: Since none of the autoreconf workaround works ===> ERROR: and autotools are not in the same directory, aborting... ===> ERROR: Updating autotools or putting all autotools in the same location ===> ERROR: may resolve the issue. -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] Issue running autogen.sh in clean git master
by Bland, Wesley 08 Nov '17

08 Nov '17

That looks like a problem of not having the latest submodules. You might need to git submodule update --init --recursive This is going to change again though when https://github.com/pmodels/mpich/pull/2851 gets merged. On Nov 8, 2017, at 9:35 AM, Lisandro Dalcin <dalcinl(a)gmail.com<mailto:[email protected]>> wrote: [dalcinl@kw14821 mpich]$ git clean -dxf . [dalcinl@kw14821 mpich]$ git branch * master [dalcinl@kw14821 mpich]$ ./autogen.sh ######################################################## ## Checking to make sure the directory structure is sane ######################################################## #################################### ## Replicating confdb (and similar) #################################### syncing 'src/mpl' --> 'src/mpi/romio/mpl' syncing 'confdb' --> 'src/mpi/romio/confdb' syncing 'confdb' --> 'test/mpi/confdb' ===> ERROR: expected to find 'aclocal_cc.m4' in 'src/mpi/romio/confdb' -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel

1 0

Issue running autogen.sh in clean git master
by Lisandro Dalcin 08 Nov '17

08 Nov '17

[dalcinl@kw14821 mpich]$ git clean -dxf . [dalcinl@kw14821 mpich]$ git branch * master [dalcinl@kw14821 mpich]$ ./autogen.sh ######################################################## ## Checking to make sure the directory structure is sane ######################################################## #################################### ## Replicating confdb (and similar) #################################### syncing 'src/mpl' --> 'src/mpi/romio/mpl' syncing 'confdb' --> 'src/mpi/romio/confdb' syncing 'confdb' --> 'test/mpi/confdb' ===> ERROR: expected to find 'aclocal_cc.m4' in 'src/mpi/romio/confdb' -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [mpich-devel] Move MPE git repo to github/pmodels ?
by Kenneth Raffenetti 03 Nov '17

03 Nov '17

Done. https://github.com/pmodels/mpe. The old location is set to read-only. Ken On 10/31/2017 02:31 PM, Lisandro Dalcin wrote: > This is a request for hosting the MPE git repo in github/pmodels. > >

1 0

Re: [mpich-devel] whitespace cleanup proposal
by Steven Oyanagi 01 Nov '17

01 Nov '17

Hi, No one is bringing up anything else besides CH3, so just CH3. - Steve -----Original Message----- From: Wesley Bland <wesley.bland(a)intel.com> Reply-To: "devel(a)mpich.org" <devel(a)mpich.org> Date: Tuesday, October 31, 2017 at 11:38 AM To: "devel(a)mpich.org" <devel(a)mpich.org> Subject: Re: [mpich-devel] whitespace cleanup proposal >That's fine with me. So are there any other parts you want to blacklist >from the cleanup script or just everything under src/mpid/ch3? > >> On Oct 31, 2017, at 11:36 AM, Steven Oyanagi <sko(a)cray.com> wrote: >> >> Hi Wesley, >> >> I am one of (and possibly the only) one who suggested that CH3 be left >> alone. I agree that the parts that will be changing in the future (mpi, >> mpid/common, util, etc) do need to be run through the code cleanup >>script. >> As you point out, not much new is going into CH3, and for those of us >>who >> will need to maintain ch3 for a while yet it would be helpful to not >>have >> to do a lot of work there due to code cleanup. >> - Steve >> >> -----Original Message----- >> From: Wesley Bland <wesley.bland(a)intel.com> >> Reply-To: "devel(a)mpich.org" <devel(a)mpich.org> >> Date: Tuesday, October 31, 2017 at 10:16 AM >> To: "devel(a)mpich.org" <devel(a)mpich.org> >> Subject: Re: [mpich-devel] whitespace cleanup proposal >> >>> I'm fine with leaving CH3 alone (I don't do much development in there), >>> but it would make this sort of thing a lot less useful if we can't run >>>it >>> on all of the other code (mpi, mpid/common, util, etc.). There's still >>> plenty of work happening there and if we're picking and choosing where >>> the code cleanup script is run, automated checking gets harder too. >>> >>>> On Oct 31, 2017, at 9:44 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> >>>> wrote: >>>> >>>> Hi folks, >>>> >>>> Some devs have expressed a desire to run the maint/code-cleanup.sh >>>> script across the whole MPICH repo. This would make all whitespace and >>>> style consistent, and give us the opportunity to use an automated >>>> checker for new code to ensure it matches the rest of the repo. >>>> >>>> There has been reasonable concern that we not run this on the >>>> src/mpid/ch3 directory, as it would be too disruptive to downstream >>>> repos. I think we are in agreement that we will leave ch3 alone, if we >>>> do this. ch4 is still early enough along that we hope it would be ok >>>>to >>>> clean up now. >>>> >>>> Please let us know if you have feedback. We'd like to make a decision >>>> regarding this prior to the 3.3b1 release at SC17. >>>> >>>> Thanks, >>>> Ken >>>> _______________________________________________ >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/devel >>> >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > >_______________________________________________ >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/devel

1 0

Move MPE git repo to github/pmodels ?
by Lisandro Dalcin 31 Oct '17

31 Oct '17

This is a request for hosting the MPE git repo in github/pmodels. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [mpich-devel] whitespace cleanup proposal
by Bland, Wesley 31 Oct '17

31 Oct '17

That's fine with me. So are there any other parts you want to blacklist from the cleanup script or just everything under src/mpid/ch3? > On Oct 31, 2017, at 11:36 AM, Steven Oyanagi <sko(a)cray.com> wrote: > > Hi Wesley, > > I am one of (and possibly the only) one who suggested that CH3 be left > alone. I agree that the parts that will be changing in the future (mpi, > mpid/common, util, etc) do need to be run through the code cleanup script. > As you point out, not much new is going into CH3, and for those of us who > will need to maintain ch3 for a while yet it would be helpful to not have > to do a lot of work there due to code cleanup. > - Steve > > -----Original Message----- > From: Wesley Bland <wesley.bland(a)intel.com> > Reply-To: "devel(a)mpich.org" <devel(a)mpich.org> > Date: Tuesday, October 31, 2017 at 10:16 AM > To: "devel(a)mpich.org" <devel(a)mpich.org> > Subject: Re: [mpich-devel] whitespace cleanup proposal > >> I'm fine with leaving CH3 alone (I don't do much development in there), >> but it would make this sort of thing a lot less useful if we can't run it >> on all of the other code (mpi, mpid/common, util, etc.). There's still >> plenty of work happening there and if we're picking and choosing where >> the code cleanup script is run, automated checking gets harder too. >> >>> On Oct 31, 2017, at 9:44 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> >>> wrote: >>> >>> Hi folks, >>> >>> Some devs have expressed a desire to run the maint/code-cleanup.sh >>> script across the whole MPICH repo. This would make all whitespace and >>> style consistent, and give us the opportunity to use an automated >>> checker for new code to ensure it matches the rest of the repo. >>> >>> There has been reasonable concern that we not run this on the >>> src/mpid/ch3 directory, as it would be too disruptive to downstream >>> repos. I think we are in agreement that we will leave ch3 alone, if we >>> do this. ch4 is still early enough along that we hope it would be ok to >>> clean up now. >>> >>> Please let us know if you have feedback. We'd like to make a decision >>> regarding this prior to the 3.3b1 release at SC17. >>> >>> Thanks, >>> Ken >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] whitespace cleanup proposal
by Steven Oyanagi 31 Oct '17

31 Oct '17

Hi Wesley, I am one of (and possibly the only) one who suggested that CH3 be left alone. I agree that the parts that will be changing in the future (mpi, mpid/common, util, etc) do need to be run through the code cleanup script. As you point out, not much new is going into CH3, and for those of us who will need to maintain ch3 for a while yet it would be helpful to not have to do a lot of work there due to code cleanup. - Steve -----Original Message----- From: Wesley Bland <wesley.bland(a)intel.com> Reply-To: "devel(a)mpich.org" <devel(a)mpich.org> Date: Tuesday, October 31, 2017 at 10:16 AM To: "devel(a)mpich.org" <devel(a)mpich.org> Subject: Re: [mpich-devel] whitespace cleanup proposal >I'm fine with leaving CH3 alone (I don't do much development in there), >but it would make this sort of thing a lot less useful if we can't run it >on all of the other code (mpi, mpid/common, util, etc.). There's still >plenty of work happening there and if we're picking and choosing where >the code cleanup script is run, automated checking gets harder too. > >> On Oct 31, 2017, at 9:44 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> >>wrote: >> >> Hi folks, >> >> Some devs have expressed a desire to run the maint/code-cleanup.sh >>script across the whole MPICH repo. This would make all whitespace and >>style consistent, and give us the opportunity to use an automated >>checker for new code to ensure it matches the rest of the repo. >> >> There has been reasonable concern that we not run this on the >>src/mpid/ch3 directory, as it would be too disruptive to downstream >>repos. I think we are in agreement that we will leave ch3 alone, if we >>do this. ch4 is still early enough along that we hope it would be ok to >>clean up now. >> >> Please let us know if you have feedback. We'd like to make a decision >>regarding this prior to the 3.3b1 release at SC17. >> >> Thanks, >> Ken >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > >_______________________________________________ >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] [mpich-intel] Sessions Considering Changing MPI_COMM_WORLD
by Bland, Wesley 31 Oct '17

31 Oct '17

That would probably be a better solution than what I mentioned above. Essentially it does the thing that we often said was possible, though we never did, which was to not actually initialize MPI_COMM_WORLD until we used it. In theory, that seemed like a good idea, but it wouldn't actually help anything because it would still require MPI_COMM_WORLD to be created sooner or later because everything gets created from it. On Oct 31, 2017, at 10:57 AM, Dinan, James <james.dinan(a)intel.com<mailto:[email protected]>> wrote: IIUC, this would break code that uses MPI_COMM_WORLD as a static initializer, e.g., to initialize a global variable like "MPI_Comm mycomm = MPI_COMM_WORLD". Why can't the handles themselves be compile-time constants corresponding to objects that are not created until the library is initialized (how it works now)? Note that such handles are defined to be compile-time constants. I don't know that they necessarily correspond to symbols that you can take an address of.

1 0