December 2015 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Announcing the availability of mpich-3.2
by Balaji, Pavan 15 Dec '15

15 Dec '15

Thank you. I've added the link to the mpich downloads page. http://www.mpich.org/downloads/ -- Pavan > On Dec 15, 2015, at 5:56 PM, Aurélien Larcher <aurelien.larcher(a)gmail.com> wrote: > > Hi, > for information, the OpenIndiana project has now updated MPICH to 3.2, compiled with GCC (4.9.3): > > http://pkg.openindiana.org/hipster-2015/en/search.shtml?token=mpich%2Fgcc > > The package provides both 32- and 64-bit versions as well as module files for environment-modules. > Best regards > > Aurelien > > On Thu, Nov 12, 2015 at 5:44 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > The MPICH team is pleased to announce the availability of a new stable release (mpich-3.2). This is the first stable release in the 3.2 series. It contains several new features, enhancements and bug fixes. > > All production environments are encouraged to upgrade to this release. > > http://www.mpich.org > > A list of changes in this release is included at the end of this email. > > Regards, > > The MPICH Team > > =============================================================================== > Changes in 3.2 > =============================================================================== > > # Added support for MPI-3.1 features including nonblocking collective I/O, > address manipulation routines, thread-safety for MPI initialization, > pre-init functionality, and new MPI_T routines to look up variables > by name. > > # Fortran 2008 bindings are enabled by default and fully supported. > > # Added support for the Mellanox MXM InfiniBand interface. (thanks > to Mellanox for the code contribution). > > # Added support for the Mellanox HCOLL interface for collectives. > (thanks to Mellanox for the code contribution). > > # Significant stability improvements to the MPICH/portals4 > implementation. > > # Completely revamped RMA infrastructure including several > scalability improvements, performance improvements, and bug fixes. > > # Added experimental support for Open Fabrics Interfaces (OFI) version 1.0.0. > https://github.com/ofiwg/libfabric (thanks to Intel for code contribution) > > # The Myrinet MX network module, which had a life cyle from 1.1 till > 3.1.2, has now been deleted. > > # Several other minor bug fixes, memory leak fixes, and code cleanup. > > A full list of changes is available at the following link: > > http://git.mpich.org/mpich.git/shortlog/v3.1.3..v3.2 > > A full list of bugs that have been fixed is available at the > following link: > > > https://trac.mpich.org/projects/mpich/query?status=closed&group=resolution&… > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > --- > Praise the Caffeine embeddings > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich-3.2 installing problem
by karl wong 15 Dec '15

15 Dec '15

Dear team, When installing mpich-3.2 with gcc on iMac X EI Capitan, I met the following problem: make[2]: *** [src/mpltrmem.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Attachment is the file you may need. For this file: mpich-3.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log, I cannot find it. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Announcing the availability of mpich-3.2
by Aurélien Larcher 15 Dec '15

15 Dec '15

Hi, for information, the OpenIndiana project has now updated MPICH to 3.2, compiled with GCC (4.9.3): http://pkg.openindiana.org/hipster-2015/en/search.shtml?token=mpich%2Fgcc The package provides both 32- and 64-bit versions as well as module files for environment-modules. Best regards Aurelien On Thu, Nov 12, 2015 at 5:44 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > The MPICH team is pleased to announce the availability of a new stable > release (mpich-3.2). This is the first stable release in the 3.2 series. It > contains several new features, enhancements and bug fixes. > > All production environments are encouraged to upgrade to this release. > > http://www.mpich.org > > A list of changes in this release is included at the end of this email. > > Regards, > > The MPICH Team > > > =============================================================================== > Changes in 3.2 > > =============================================================================== > > # Added support for MPI-3.1 features including nonblocking collective I/O, > address manipulation routines, thread-safety for MPI initialization, > pre-init functionality, and new MPI_T routines to look up variables > by name. > > # Fortran 2008 bindings are enabled by default and fully supported. > > # Added support for the Mellanox MXM InfiniBand interface. (thanks > to Mellanox for the code contribution). > > # Added support for the Mellanox HCOLL interface for collectives. > (thanks to Mellanox for the code contribution). > > # Significant stability improvements to the MPICH/portals4 > implementation. > > # Completely revamped RMA infrastructure including several > scalability improvements, performance improvements, and bug fixes. > > # Added experimental support for Open Fabrics Interfaces (OFI) version > 1.0.0. > https://github.com/ofiwg/libfabric (thanks to Intel for code > contribution) > > # The Myrinet MX network module, which had a life cyle from 1.1 till > 3.1.2, has now been deleted. > > # Several other minor bug fixes, memory leak fixes, and code cleanup. > > A full list of changes is available at the following link: > > http://git.mpich.org/mpich.git/shortlog/v3.1.3..v3.2 > > A full list of bugs that have been fixed is available at the > following link: > > > > https://trac.mpich.org/projects/mpich/query?status=closed&group=resolution&… > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- --- Praise the Caffeine embeddings _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPE animation crash
by Schilling, Herbert W. (GRC-VE00) 15 Dec '15

15 Dec '15

Hi Rob, Thanks for the response! It's amazing to get responses from people I see in videos that I watch about MPI. I will try to find some time to see if I can fix the animation crash. I hope I can find a much smaller sample code with the same problem. It would be a pain to debug this with the huge code that I am running now. Yes, definitely will use valgrind. Have used it before. About the question the actual animations, I may not have asked the question correctly or I am not reading your response correctly. I wanted to know what the arrows are trying to show in the sense of which 'mode' of sends are these? Or are all the sends shown the same way? Are bcasts, scatters, gathers shown differently ? Are they shown at all? I guess I can just try some sample codes to figure that out or look through the code. Just hoped it was written down somewhere. Thanks! On Dec 14, 2015, at 12:22 PM, Rob Latham <robl(a)mcs.anl.gov<mailto:[email protected]>> wrote: On 12/09/2015 09:18 AM, Schilling, Herbert W. (GRC-VE00) wrote: Hi, First of all, thanks again to everyone, especially Bill Gropp, for modifying MPE so it works with OpenMPI. I did see a post somewhere about how the MPE animation code hasn't been updated in a while. Is it still something that should be good to use? It's a nice feature! In our code, it works for a while and then crashes with this sorry you're running into problems with the MPE animation code. As you've seen, every once in a while one of us (probably Bill) will go in and clean up MPE, but for the most part it's community supported. If you code up a fix, we'll gladly add it to MPE. [ snip error] What is really odd is that one I ran the exact same code with the exact same command and it died much earlier while doing some kind of memory allocation. Unfortunately, I didn't capture that error and I can't make it happen again now. such is the case with memory errors. A tool like valgrind can tell you what's going on. Also, without digging through the code to figure out how the animations are being displayed, is there any documentation on that? Appendix C of "Using MPI" might be the best overview. The book also walks through a simnple monte carlo example in section 3.10 on page 65. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss --------- Herb Schilling Scientific Applications and Visualization Team http://ocio.grc.nasa.gov/gvis Office of the Chief Information Officer NASA Glenn Research Center hschilling(a)nasa.gov<mailto:[email protected]> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPE animation crash
by Rob Latham 14 Dec '15

14 Dec '15

On 12/09/2015 09:18 AM, Schilling, Herbert W. (GRC-VE00) wrote: > Hi, > > First of all, thanks again to everyone, especially Bill Gropp, for > modifying MPE so it works with OpenMPI. > > I did see a post somewhere about how the MPE animation code hasn't > been updated in a while. Is it still something that should be good to > use? It's a nice feature! > > In our code, it works for a while and then crashes with this sorry you're running into problems with the MPE animation code. As you've seen, every once in a while one of us (probably Bill) will go in and clean up MPE, but for the most part it's community supported. If you code up a fix, we'll gladly add it to MPE. [ snip error] > > What is really odd is that one I ran the exact same code with the exact > same command and it died much earlier while doing some kind of memory > allocation. Unfortunately, I didn't capture that error and I can't make > it happen again now. such is the case with memory errors. A tool like valgrind can tell you what's going on. > > Also, without digging through the code to figure out how the animations > are being displayed, is there any documentation on that? Appendix C of "Using MPI" might be the best overview. The book also walks through a simnple monte carlo example in section 3.10 on page 65. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Balaji, Pavan 12 Dec '15

12 Dec '15

Thanks. It's unlikely it'll be in the 3.2.x series, so 3.3 is a safe bet for it (it's not about timing; just that it doesn't look like a minor release change). We'll take care of moving the tickets to the right milestone. -- Pavan > On Dec 12, 2015, at 4:23 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > I created https://trac.mpich.org/projects/mpich/ticket/2319#ticket. I set the milestone to 3.2.3, although I expect someone who actually works on MPICH will change this :-) > > Jeff > > On Fri, Dec 11, 2015 at 11:08 PM, Jed Brown <jed(a)jedbrown.org> wrote: > So what's the plan here? Is MPICH-3.3 going to return to the expected behavior? > > William Gropp <wgropp(a)illinois.edu> writes: > > > I agree. This is a perverse interpretation. While I understand the optimization, the nonblocking routines should return an active request, not a null request. (The real optimization is probably in not creating the request, rather than freeing it; while requests should be managed in such a way that creation is cheap, its likely that defensive coding will initialize the request, which can be non-trivial. Still, this doesn’t seem worth the surprise to the user.) > > > > Bill > > > > William Gropp > > Director, Parallel Computing Institute > > Thomas M. Siebel Chair in Computer Science > > Chief Scientist, NCSA > > University of Illinois Urbana-Champaign > > > > > > > > > > > > On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > > >> I understand the optimization here, but I think Jed does have a point: it is weird. > >> > >> Further, MPI-3.1 5.1.2 p196:38-39 states: > >> > >> "A nonblocking call initiates a collective operation, which must be completed in a separate completion call." > >> > >> Arguably, this does not directly state that you need to return a valid request from any of the NBCs. But it's a reasonable interpretation to believe that it should. > >> > >> Further, Jed is right that this might be a micro-optimization (i.e., avoiding the creation or deallocation of a request), but it doesn't help much unless the app also does an associated "if" to test and see if the request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., that would be a further micro-optimization -- which probably isn't negated by the app's "if" because TEST*/WAIT* have to do the same "if" for REQUEST_NULL). > >> > >> In short: yes, this is a micro-optimization. But: > >> > >> a) it kinda falls in the "violates the law of least astonishment" category > >> b) is deallocating a free listed request that expensive? > >> c) if you have to explain this every time, are you really optimizing anything? > >> d) it's a single process case -- it's already damn fast. Do you really need to optimize it further? :-) > >> > >> (To be clear: I don't really care; I just bring up these points to highlight the other side of the story) > >> > >> > >>> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >>> > >>> Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here. > >>> > >>> Why don't you use MPI_Test instead of direct comparison? > >>> > >>> Jeff > >>> > >>> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >>> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == > >>> MPI_REQUEST_NULL. This is also the case for other communicators of size > >>> 1. Previous versions of MPICH and also all versions of Open MPI return > >>> a valid request not equal to MPI_REQUEST_NULL. This bit me because it > >>> was natural to compare to MPI_REQUEST_NULL in a conditional for an > >>> Ibarrier/Issend/Iprobe algorithm. It can be worked around with a > >>> slightly more complicate conditional, but is this change intentional? > >>> > >>> The call returns a request handle, which must be passed to a > >>> completion call. > >>> -- MPI-3 §5.12 > >>> > >>> This does not say "unless the communicator has size 1". > >>> > >>> _______________________________________________ > >>> discuss mailing list discuss(a)mpich.org > >>> To manage subscription options or unsubscribe: > >>> https://lists.mpich.org/mailman/listinfo/discuss > >>> > >>> > >>> > >>> -- > >>> Jeff Hammond > >>> jeff.science(a)gmail.com > >>> http://jeffhammond.github.io/ > >>> _______________________________________________ > >>> discuss mailing list discuss(a)mpich.org > >>> To manage subscription options or unsubscribe: > >>> https://lists.mpich.org/mailman/listinfo/discuss > >> > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jeff Hammond 12 Dec '15

12 Dec '15

I created https://trac.mpich.org/projects/mpich/ticket/2319#ticket. I set the milestone to 3.2.3, although I expect someone who actually works on MPICH will change this :-) Jeff On Fri, Dec 11, 2015 at 11:08 PM, Jed Brown <jed(a)jedbrown.org> wrote: > So what's the plan here? Is MPICH-3.3 going to return to the expected > behavior? > > William Gropp <wgropp(a)illinois.edu> writes: > > > I agree. This is a perverse interpretation. While I understand the > optimization, the nonblocking routines should return an active request, not > a null request. (The real optimization is probably in not creating the > request, rather than freeing it; while requests should be managed in such a > way that creation is cheap, its likely that defensive coding will > initialize the request, which can be non-trivial. Still, this doesn’t seem > worth the surprise to the user.) > > > > Bill > > > > William Gropp > > Director, Parallel Computing Institute > > Thomas M. Siebel Chair in Computer Science > > Chief Scientist, NCSA > > University of Illinois Urbana-Champaign > > > > > > > > > > > > On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> > wrote: > > > >> I understand the optimization here, but I think Jed does have a point: > it is weird. > >> > >> Further, MPI-3.1 5.1.2 p196:38-39 states: > >> > >> "A nonblocking call initiates a collective operation, which must be > completed in a separate completion call." > >> > >> Arguably, this does not directly state that you need to return a valid > request from any of the NBCs. But it's a reasonable interpretation to > believe that it should. > >> > >> Further, Jed is right that this might be a micro-optimization (i.e., > avoiding the creation or deallocation of a request), but it doesn't help > much unless the app also does an associated "if" to test and see if the > request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., > that would be a further micro-optimization -- which probably isn't negated > by the app's "if" because TEST*/WAIT* have to do the same "if" for > REQUEST_NULL). > >> > >> In short: yes, this is a micro-optimization. But: > >> > >> a) it kinda falls in the "violates the law of least astonishment" > category > >> b) is deallocating a free listed request that expensive? > >> c) if you have to explain this every time, are you really optimizing > anything? > >> d) it's a single process case -- it's already damn fast. Do you really > need to optimize it further? :-) > >> > >> (To be clear: I don't really care; I just bring up these points to > highlight the other side of the story) > >> > >> > >>> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > >>> > >>> Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier > (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially > complete and it would seem that MPICH is optimizing away the unnecessary > request object here. > >>> > >>> Why don't you use MPI_Test instead of direct comparison? > >>> > >>> Jeff > >>> > >>> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >>> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == > >>> MPI_REQUEST_NULL. This is also the case for other communicators of > size > >>> 1. Previous versions of MPICH and also all versions of Open MPI return > >>> a valid request not equal to MPI_REQUEST_NULL. This bit me because it > >>> was natural to compare to MPI_REQUEST_NULL in a conditional for an > >>> Ibarrier/Issend/Iprobe algorithm. It can be worked around with a > >>> slightly more complicate conditional, but is this change intentional? > >>> > >>> The call returns a request handle, which must be passed to a > >>> completion call. > >>> -- MPI-3 §5.12 > >>> > >>> This does not say "unless the communicator has size 1". > >>> > >>> _______________________________________________ > >>> discuss mailing list discuss(a)mpich.org > >>> To manage subscription options or unsubscribe: > >>> https://lists.mpich.org/mailman/listinfo/discuss > >>> > >>> > >>> > >>> -- > >>> Jeff Hammond > >>> jeff.science(a)gmail.com > >>> http://jeffhammond.github.io/ > >>> _______________________________________________ > >>> discuss mailing list discuss(a)mpich.org > >>> To manage subscription options or unsubscribe: > >>> https://lists.mpich.org/mailman/listinfo/discuss > >> > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jed Brown 12 Dec '15

12 Dec '15

So what's the plan here? Is MPICH-3.3 going to return to the expected behavior? William Gropp <wgropp(a)illinois.edu> writes: > I agree. This is a perverse interpretation. While I understand the optimization, the nonblocking routines should return an active request, not a null request. (The real optimization is probably in not creating the request, rather than freeing it; while requests should be managed in such a way that creation is cheap, its likely that defensive coding will initialize the request, which can be non-trivial. Still, this doesn’t seem worth the surprise to the user.) > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > Chief Scientist, NCSA > University of Illinois Urbana-Champaign > > > > > > On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> I understand the optimization here, but I think Jed does have a point: it is weird. >> >> Further, MPI-3.1 5.1.2 p196:38-39 states: >> >> "A nonblocking call initiates a collective operation, which must be completed in a separate completion call." >> >> Arguably, this does not directly state that you need to return a valid request from any of the NBCs. But it's a reasonable interpretation to believe that it should. >> >> Further, Jed is right that this might be a micro-optimization (i.e., avoiding the creation or deallocation of a request), but it doesn't help much unless the app also does an associated "if" to test and see if the request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., that would be a further micro-optimization -- which probably isn't negated by the app's "if" because TEST*/WAIT* have to do the same "if" for REQUEST_NULL). >> >> In short: yes, this is a micro-optimization. But: >> >> a) it kinda falls in the "violates the law of least astonishment" category >> b) is deallocating a free listed request that expensive? >> c) if you have to explain this every time, are you really optimizing anything? >> d) it's a single process case -- it's already damn fast. Do you really need to optimize it further? :-) >> >> (To be clear: I don't really care; I just bring up these points to highlight the other side of the story) >> >> >>> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here. >>> >>> Why don't you use MPI_Test instead of direct comparison? >>> >>> Jeff >>> >>> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == >>> MPI_REQUEST_NULL. This is also the case for other communicators of size >>> 1. Previous versions of MPICH and also all versions of Open MPI return >>> a valid request not equal to MPI_REQUEST_NULL. This bit me because it >>> was natural to compare to MPI_REQUEST_NULL in a conditional for an >>> Ibarrier/Issend/Iprobe algorithm. It can be worked around with a >>> slightly more complicate conditional, but is this change intentional? >>> >>> The call returns a request handle, which must be passed to a >>> completion call. >>> -- MPI-3 §5.12 >>> >>> This does not say "unless the communicator has size 1". >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] cross comiling MPICH
by Doha Ehab 10 Dec '15

10 Dec '15

when I add -lpthread gives the following error checking whether the C compiler works... no configure: error: C compiler cannot create executables On Thu, Dec 10, 2015 at 4:37 PM, <Florian.Willich(a)dlr.de> wrote: > Does it work to just add the pthread lib to your libs?: > > ./configure --host=arm-linux-androideabi > --prefix=/Crosscompile2/jni/mpich/ LIBS="-lc -lgcc -lpthread" > --disable-shared --disable-fortran --disable-cxx > > ------------------------------ > *Von:* Doha Ehab [dohaehab(a)gmail.com] > *Gesendet:* Donnerstag, 10. Dezember 2015 15:29 > *An:* discuss(a)mpich.org > *Betreff:* [mpich-discuss] cross comiling MPICH > > Hello , > I'm trying to use Android toolchain to cross compile mpi using the > following commands: > > export > PATH="$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/:$PATH" > export SYS_ROOT="$NDK_ROOT/platforms/android-8/arch-arm/" > export CC="arm-linux-androideabi-gcc --sysroot=$SYS_ROOT" > export LD="arm-linux-androideabi-ld" > export AR="arm-linux-androideabi-ar" > > > ./configure --host=arm-linux-androideabi > --prefix=/Crosscompile2/jni/mpich/ LIBS="-lc -lgcc " --disable-shared > --disable-fortran --disable-cxx > > but I got the following error > > checking for pthread_key_create in -lpthread... no > checking checkpointing library... configure: error: pthreads is required > for checkpointing, but was not found > configure: error: src/pm/hydra configure failed > > I also have attached the config.log but I don't know what is the problem. > > Thanks > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] cross comiling MPICH
by Florian.Willich＠dlr.de 10 Dec '15

10 Dec '15

Does it work to just add the pthread lib to your libs?: ./configure --host=arm-linux-androideabi --prefix=/Crosscompile2/jni/mpich/ LIBS="-lc -lgcc -lpthread" --disable-shared --disable-fortran --disable-cxx ________________________________ Von: Doha Ehab [dohaehab(a)gmail.com] Gesendet: Donnerstag, 10. Dezember 2015 15:29 An: discuss(a)mpich.org Betreff: [mpich-discuss] cross comiling MPICH Hello , I'm trying to use Android toolchain to cross compile mpi using the following commands: export PATH="$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/:$PATH" export SYS_ROOT="$NDK_ROOT/platforms/android-8/arch-arm/" export CC="arm-linux-androideabi-gcc --sysroot=$SYS_ROOT" export LD="arm-linux-androideabi-ld" export AR="arm-linux-androideabi-ar" ./configure --host=arm-linux-androideabi --prefix=/Crosscompile2/jni/mpich/ LIBS="-lc -lgcc " --disable-shared --disable-fortran --disable-cxx but I got the following error checking for pthread_key_create in -lpthread... no checking checkpointing library... configure: error: pthreads is required for checkpointing, but was not found configure: error: src/pm/hydra configure failed I also have attached the config.log but I don't know what is the problem. Thanks _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0