MPICH 2 is portable MPI implementation with bindings for fortran, and c++. Quoting from the website: "The goals of MPICH2 are to provide an MPI implementation for important platforms, including clusters, SMPs, and massively parallel processors. It also provides a vehicle for MPI implementation research and for developing new and better parallel programming environments." "It has been extensively tested on several platforms, including Linux (on IA32 and IA64)..." please find attached file mpich2-1.0.1.ebuild.
Created attachment 62103 [details] mpich2-1.0.1.ebuild (New Package)
Why cluster@gentoo.org people do not want to maintain also mpich2, when they already do care about mpich? At least if you'd push it into the tree. ;)
I tried the ebuild and the inclusion of those two fortran-related configure options makes somehow configure to have unset the f77/g77 variable and it simply dies that it cannot find the fortran compiler. Thus, I commented out the code checking for "fortran" USE flag. I had to add cd(1) calls into two sections and tested with current bugfix release 1.0.2p1. Will attach the updated ebuild. I'm not very happy with the fact that mpich2-1.0.2p1.ebuild is not a valid name for portage, so had to rename it to mpich2-1.0.2.1.ebuild. :( Thus, there's ${PNAME} variable in the ebuild file housing original filename. The src_isntall() step is still broken, i.e. "make install" tries to modify directly /usr/examples/. Hope someone will fix it. ;)
Created attachment 66658 [details] mpich2-1.0.2.1.ebuild (not working yet) Feel free to fix the src_install step: Make completed make[1]: Leaving directory `/var/tmp/portage/mpich2-1.0.2.1/work/mpich2-1.0.2p1' >>> Test phase [not enabled]: sys-cluster/mpich2-1.0.2.1 >>> Install mpich2-1.0.2.1 into /var/tmp/portage/mpich2-1.0.2.1/image/ category sys-cluster if [ ! -d /usr ] ; then mkdir -p /usr ; fi if [ ! -d /usr/www ] ; then mkdir -p /usr/www ; fi if [ ! -d /usr/share/man ] ; then mkdir -p /usr/share/man ; fi if [ ! -d /usr/include ] ; then mkdir -p /usr/include ; fi make install-local make[1]: Entering directory `/var/tmp/portage/mpich2-1.0.2.1/work/mpich2-1.0.2p1' if [ "no" = "yes" ] ; then \ /bin/install -c -m 644 src/mpi/debugger/libtvmpich.so \ /usr/lib/libtvmpich.so ; fi if test ! -d /usr/examples ; then \ mkdir -p /usr/examples ; \ fi /bin/install -c examples/cpi /usr/examples/cpi ACCESS DENIED unlink: /usr/examples/cpi /bin/install: cannot remove `/usr/examples/cpi': Permission denied make[1]: *** [install-local] Error 1 make[1]: Leaving directory `/var/tmp/portage/mpich2-1.0.2.1/work/mpich2-1.0.2p1' make: *** [install] Error 2 !!! ERROR: sys-cluster/mpich2-1.0.2.1 failed. !!! Function src_install, Line 75, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-sys-cluster_-_mpich2-1.0.2.1-6115.log" unlink: /usr/examples/cpi --------------------------------------------------------------------------------
(In reply to comment #2) > Why cluster@gentoo.org people do not want to maintain also mpich2, when they > already do care about mpich? At least if you'd push it into the tree. ;) We are interested it, yes. But we don't have the resources to maintain it right now. Once we either get more people, our current members shift their priorities or get more time, then hopefully something can be done.
BTW: I have filed several bugreports to the upstream maintainers for both, mpich and mpich2, related to configure's behaviour etc. Will answer back once I get things working for me well. I'd like to have both mpichs capable to use icc instead of gcc as cc and c++ compilers.
Created attachment 70311 [details] Working ebuild for mpich2-1.0.2p1 I've created a working ebuild for mpich2, based on thing posted here. I needed to disable MPE tough, which is a simple ./configure option "--disable-mpe". Without this it tries to install files to /usr/includes, outside the sandbox. More Makefile hacking need to be done to enable MPE. This is surely not the cleanest way of doing this (its my first ebuild), but I least it emerges right. mpd is running ok. I should add an init script to launch it at boot. I have one already for archlinux, will adapt it for gentoo.
Created attachment 72987 [details] mpich2-1.0.2_p1.ebuild Here's my working version. Still not perfect, but I haven't had time to look at it lately so I thought I'd post it.
(In reply to comment #8) > Created an attachment (id=72987) [edit] > mpich2-1.0.2_p1.ebuild > > Here's my working version. Still not perfect, but I haven't had time to look at > it lately so I thought I'd post it. Some of the spacing is pretty screwed up on that; it all needs to get converted to tabs.
The main problem, as I recall, is that a number of files from some subdirectory of mpe install to really strange places.
Created attachment 73312 [details] ebuild update Updated ebuild
I've check a bit on the dependency of mpich2 and updated the ebuild. I'm compiling it with Intel compilers (icc and ifort) since (stable) gcc only support fortran 77 and I need fortran 90. But since enabling only "fortran" use flag is not enought to distinguish between "use gcc's fortran 77" or "use intel's fortran 77 & 90" I've put a new use flag "fortran90". So if that useflag is set but not "ifc", the package would depend on gcc 4, which I think (I'm really not sure) support fortran 95 (merging of g95 project)?. Is this new use flag "fortran90" against gentoo? I hope not... There is also a dependency use flag about python. It will build mpd which is written in python or forker wich is in C. MPE is still disabled, since I don't use it and didn't have the time to check this. (In reply to comment #9) > Some of the spacing is pretty screwed up on that; it all needs to get converted > to tabs. I've found 3 or 4 of those... Is it ok now?
(In reply to comment #12) > I've check a bit on the dependency of mpich2 and updated the ebuild. > > I'm compiling it with Intel compilers (icc and ifort) since (stable) gcc only > support fortran 77 and I need fortran 90. But since enabling only "fortran" use > flag is not enought to distinguish between "use gcc's fortran 77" or "use > intel's fortran 77 & 90" I've put a new use flag "fortran90". So if that useflag > is set but not "ifc", the package would depend on gcc 4, which I think (I'm > really not sure) support fortran 95 (merging of g95 project)?. ifc should not be a USE flag, it should be a CC setting retrieved with tc-getCC() from toolchain-funcs.eclass if there's any required changes for ifc. I don't see anything truly ifc-dependent in this ebuild that belongs in the ebuild; the only possible thing is setting F90, but that also should be done when using gfortran with gcc-4. > > Is this new use flag "fortran90" against gentoo? I hope not... Already had been added to my ebuild as f90 > > There is also a dependency use flag about python. It will build mpd which is > written in python or forker wich is in C. Interesting. But should this really be a python flag, despite it using python? It seems to me the real choice is between mpd and forker. > > MPE is still disabled, since I don't use it and didn't have the time to check this. Fixed in my ebuild > > (In reply to comment #9) > > Some of the spacing is pretty screwed up on that; it all needs to get converted > > to tabs. > I've found 3 or 4 of those... Is it ok now? I would prefer that you based your work on my ebuild rather than continuing to modify the others, because it fixed a number of the problems in the older ebuilds, such as mpe, some style, and using fortran.eclass.
(In reply to comment #13) Didn't see your post! Still new to bugzilla's structure ;) And I still discover some really powerfull things about gentoo... > ifc should not be a USE flag, it should be a CC setting retrieved with > tc-getCC() from toolchain-funcs.eclass if there's any required changes for ifc. > I don't see anything truly ifc-dependent in this ebuild that belongs in the > ebuild; the only possible thing is setting F90, but that also should be done > when using gfortran with gcc-4. So you suggest the ebuild should be "standard", whatever compiler used? And letting the ebuild choose the compiler based on another eclass or profile? > Interesting. But should this really be a python flag, despite it using python? > It seems to me the real choice is between mpd and forker. I would think so. The choice is between mpd and forker, but are not build the same way, so depends on different things. As of the Installer's guide (http://www-unix.mcs.anl.gov/mpi/mpich2/downloads/mpich2-doc-install.pdf): Python 2.2 or later version, for building the default process manage- ment system, MPD. In addition, you will need PyXML and an XML parser such as expat (in order to use mpiexec with the MPD pro- cess manager). Most systems have Python, PyXML, and expat pre- installed, but you can get them free from www.python.org. You may assume they are there unless the configure step below complains. Those dependencies (python, pyxml and expat) are only for mpd, no? So they are not needed if forker (or other...) is build. > Fixed in my ebuild Excellent :) > I would prefer that you based your work on my ebuild rather than continuing to > modify the others, because it fixed a number of the problems in the older > ebuilds, such as mpe, some style, and using fortran.eclass. Sorry about that, I didn't saw your post! Is posting patch for ebuilds a better way? Does fortran.eclass support fortran 90? Two additions. -There is a "--enable-f90modules" configure option. Is it redundant or could be used? I've included since the begining, but I'm not sure if it needed. -I'm trying to do a init.d script for mpd so it is launched at startup. Good or bad idea? About the tabs thing, there seems to be some mixture of tabs and spaces in attachment id=72987. Is it bugzilla doing this? I'm emerging your ebuild with the init.d script and python use flag dependency but because of those tabs a diff would be uselessly big...
(In reply to comment #14) > So you suggest the ebuild should be "standard", whatever compiler used? And > letting the ebuild choose the compiler based on another eclass or profile? The compiler will be set using either gcc-config or overridden using the CC, F77, F90 etc environment variables. USE flags should have nothing to do with this. That's why I removed the parts of the ebuild with `use ifc` && foo. > > Interesting. But should this really be a python flag, despite it using python? > > It seems to me the real choice is between mpd and forker. > > I would think so. The choice is between mpd and forker, but are not build the > same way, so depends on different things. As of the Installer's guide > (http://www-unix.mcs.anl.gov/mpi/mpich2/downloads/mpich2-doc-install.pdf): > Python 2.2 or later version, for building the default process manage- > ment system, MPD. In addition, you will need PyXML and an XML > parser such as expat (in order to use mpiexec with the MPD pro- > cess manager). Most systems have Python, PyXML, and expat pre- > installed, but you can get them free from www.python.org. You may > assume they are there unless the configure step below complains. > Those dependencies (python, pyxml and expat) are only for mpd, no? So they are > not needed if forker (or other...) is build. Right, but in general I don't see the name of this choice being "python." And all I'm talking about is the name of the USE flag here, not whether the choice exists. People who want mpd want mpd, and they don't care at all whether it's in python, ada or c++. So having the flag named after the language it's implemented in doesn't make much sense to me. > Sorry about that, I didn't saw your post! Is posting patch for ebuilds a > better way? Not when they're all on a bug like this; then people need to go through and put all the patches together. Patches are better when they're just against an ebuild already in the tree, however. > Does fortran.eclass support fortran 90? Not yet, but that needs to get fixed. It shouldn't be too bad, as most of the eclass consists of a single function. The sci@g.o team already knows about this, and hopefully will fix it soon if we don't come up with a fix here. > Two additions. > -There is a "--enable-f90modules" configure option. Is it redundant or could be > used? I've included since the begining, but I'm not sure if it needed. I didn't find this anywhere in the mpich2 documentation or in `./configure --help` output or grepping the tree. So I'm not sure it does anything. > -I'm trying to do a init.d script for mpd so it is launched at startup. Good > or bad idea? Great idea. All daemons that don't start automatically should get an init script. > About the tabs thing, there seems to be some mixture of tabs and spaces in > attachment id=72987. Is it bugzilla doing this? I'm emerging your ebuild with > the init.d script and python use flag dependency but because of those tabs a > diff would be uselessly big... I'm not sure where those came from. It's pretty weird. But anyway, no need to attach diffs; just attach the whole new ebuild.
(In reply to comment #15) > The compiler will be set using either gcc-config or overridden using the CC, > F77, F90 etc environment variables. USE flags should have nothing to do with > this. That's why I removed the parts of the ebuild with `use ifc` && foo. Interesting. And icc is not the only compiler alternative. Mooving this use flag out gets my support ;) It seems, from the wiki (http://gentoo-wiki.com/HOWTO_ICC_and_Portage), that icc is not supported yet: Additionally, as there is no support for icc in gcc-config, we will have to override the variables it sets for CC and CXX. > Right, but in general I don't see the name of this choice being "python." And > all I'm talking about is the name of the USE flag here, not whether the choice > exists. People who want mpd want mpd, and they don't care at all whether it's in > python, ada or c++. So having the flag named after the language it's implemented > in doesn't make much sense to me. Yeah I know, but how can a choice be made for it? Another use flag for mpd?
Created attachment 73379 [details] init.d script for mpd This is the init.d script I've done for mpd. I've tested it a litle bit, but not much. It does seems to work. The ebuild should contain another line in src_install() to install it: doinitd ${FILESDIR}/mpd
(In reply to comment #16) > Yeah I know, but how can a choice be made for it? Another use flag for mpd? Have the flag for the non-default. mpd is default, no? Then the flag would be forker.
Created attachment 73382 [details] Updated ebuild with init script and use flag "forker" use flag is included. It will build with mpd and against python if not set. The initscript is also installed with it.
Created attachment 73383 [details] Updated ebuild with init script and use flag "forker" use flag is included. It will build with mpd and against python if not set. The initscript is also installed with it.
I see that icc is still hiding in IUSE. Should the mpd init script be installed conditionally on whether mpd or forker is built? Also, notice the f90modules thing is still there.
Created attachment 73386 [details] Corrected Damit I missed those :)
MPICH2 v1.0.3 is out. The ebuild seems to still work. (In reply to comment #15) > The compiler will be set using either gcc-config or overridden using the CC, > F77, F90 etc environment variables. USE flags should have nothing to do with > this. That's why I removed the parts of the ebuild with `use ifc` && foo. Does gcc-config works (and if so, how to configure it?) or is the only way to emerge this with icc/ifc is: cc="icc" CC="icc" CXX="icc" F90="ifc" FC="ifc" emerge mpich2 ?
(In reply to comment #23) > cc="icc" CC="icc" CXX="icc" F90="ifc" FC="ifc" emerge mpich2 like that, but the cc shouldn't be necessary and we should be able to set it up so F90 defaults to FC if unset.
BTW if you want to use any of those for all packages, just set them in make.conf.
(In reply to comment #25) > BTW if you want to use any of those for all packages, just set them in make.conf. But if I only want it for mpich2?
(In reply to comment #26) > But if I only want it for mpich2? Then you go with the original suggestion of environment variables. We've been looking for an icc guy for quite a while who would enhance gcc-config to allow separate configuration of F77, CC and CXX so one could e.g. have CC=gcc, F77=ifc, but none of them have ever been dedicated enough to stick around.
Someone committed an mpich2 ebuild when I wasn't paying attention. Give it a shot and file _new_ bugs assigned to kanaka at gentoo.org for any problems you encounter. I already know it doesn't work with gcc-4 yet.
*** Bug 222747 has been marked as a duplicate of this bug. ***
