Package Details: mpich 4.0.2-1

Git Clone URL: https://aur.archlinux.org/mpich.git (read-only, click to copy)
Package Base: mpich
Description: An improved implementation of the Message Passing Interface.
Upstream URL: https://mpich.org
Licenses: custom
Replaces: mpich2
Submitter: jedbrown
Maintainer: jedbrown
Last Packager: jedbrown
Votes: 88
Popularity: 0.008518
First Submitted: 2012-12-31 21:25 (UTC)
Last Updated: 2022-05-19 03:26 (UTC)

Latest Comments

stockholmsin commented on 2022-05-17 19:20 (UTC)

That was a packaging bug in binutils that should have been fixed by https://github.com/archlinux/svntogit-packages/commit/e4cb74545d27e087aae4bd8b796ec6b0ba5870ac Everything seems to build correctly for me now.

jedbrown commented on 2022-04-08 18:47 (UTC)

I've had builds fail (in the bundled ucx) with 4.0.1 and 4.0.2 due to the error below. I haven't had time to reduce yet, but if you know what's up or can find an upstream bug report, that would help.

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libiberty.a(rust-demangle.o): warning: relocation against `_sch_istable' in read-only section `.text'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libiberty.a(cp-demangle.o): relocation R_X86_64_PC32 against symbol `cplus_demangle_builtin_types' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value

carlosal1015 commented on 2021-05-17 14:47 (UTC) (edited on 2021-07-06 16:16 (UTC) by carlosal1015)

Edited 2021/06/15: Thank you for solve the issue, now is compiling smooth as before.

RonObvious commented on 2021-01-09 15:45 (UTC)

Thanks for the tip. I tried your first suggestion, adding --without-java (between --with-device=ch4:ucx and --with-hwloc-prefix=/usr) and the package now builds successfully. I haven't tested it to any great extent, but it builds and mpichversion runs... Enough for the time being. Thanks again!

jedbrown commented on 2021-01-08 22:40 (UTC)

Could you try adding the --without-java flag to the PKGBUILD? Alternatively, you can switch back to --with-device=ch3:nemesis, which doesn't involve building ucx.

RonObvious commented on 2021-01-08 21:36 (UTC) (edited on 2021-01-08 21:38 (UTC) by RonObvious)

About the new version (8 Jan 2021): My build stops with the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jucx: Compilation failure

[ERROR] (the directory I'm using...) mpich/src/mpich-3.4/modules/ucx/bindings/java/src/main/java/org/openucx/jucx/UcxUtils.java:[40,28] package sun.nio.ch does not exist

I have a "java-environment" installed, thus fulfilling the "optdepends" -- to be more precise, I have jdk-openjdk installed (and maven and various other java things).

Is this perhaps a problem withe make files which mpich is using (and not an AUR package problem)?

Whether it is or not, as a workaround, do you have any tips about how to modify the PKGBUILD (or .SRCINFO, etc.) to NOT build the java stuff, even if a java-envronment is present? I really do not plan to use mpich with Java (at least not right away).

More details about my setup on request.

wcdawn commented on 2020-06-11 19:36 (UTC)

I just compiled successfully. Fortran seems to be working now.

deep_thought commented on 2020-05-18 07:55 (UTC)

This fails to build - probably due to gcc-fortran 10.1.0:

checking whether gfortran allows mismatched arguments... no configure: error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

(The same holds for mpich2)

regards, deep_thought

polarathene commented on 2018-06-29 09:02 (UTC)

Build failing due to error "strncmp is required"? How to resolve?

In file included from ../../../src/mpl/include/mpl.h:111, from ../../../src/mpl/src/mpltrmem.c:16: ../../../src/mpl/include/mplstr.h:48:2: error: #error "strncmp is required" #error "strncmp is required" ^~~~~ In file included from ../../../src/mpl/include/mpl.h:111, from ../../../src/mpl/src/mplenv.c:7: ../../../src/mpl/include/mplstr.h:48:2: error: #error "strncmp is required" #error "strncmp is required" ^~~~~ ../../../src/mpl/src/mpltrmem.c:36:12: error: conflicting types for ‘free’ extern int free(void ); ^~~~ In file included from ../../../src/mpl/include/mpl.h:111, from ../../../src/mpl/src/mplmsg.c:7: ../../../src/mpl/include/mplstr.h:48:2: error: #error "strncmp is required" #error "strncmp is required" ^~~~~ In file included from ../../../src/mpl/include/mpl.h:13, from ../../../src/mpl/src/mpltrmem.c:16: /usr/include/stdlib.h:563:13: note: previous declaration of ‘free’ was here extern void free (void ptr) THROW; ^~~~ In file included from ../../../src/mpl/include/mpl.h:111, from ../../../src/mpl/src/mplstr.c:7: ../../../src/mpl/include/mplstr.h:48:2: error: #error "strncmp is required" #error "strncmp is required" ^~~~~ ../../../src/mpl/src/mplenv.c: In function ‘MPL_env2range’: ../../../src/mpl/src/mplenv.c:21:22: warning: implicit declaration of function ‘isspace’ [-Wimplicit-function-declaration] while (p && isspace(p)) ^~~~~~~ ../../../src/mpl/src/mplenv.c:23:22: warning: implicit declaration of function ‘isdigit’ [-Wimplicit-function-declaration] while (p && isdigit(p)) ^~~~~~~ ../../../src/mpl/src/mplstr.c: In function ‘MPL_snprintf’: ../../../src/mpl/src/mplstr.c:41:17: warning: implicit declaration of function ‘isdigit’ [-Wimplicit-function-declaration] if (isdigit(nc)) { ^~~~~~~ make[2]: [Makefile:732: src/mplenv.lo] Error 1 make[2]: Waiting for unfinished jobs.... make[2]: [Makefile:732: src/mplmsg.lo] Error 1 make[2]: [Makefile:732: src/mpltrmem.lo] Error 1 make[2]: [Makefile:732: src/mplstr.lo] Error 1 make[2]: Leaving directory '/tmp/.cache/aur/mpich/src/mpich-3.2.1/build/src/mpl' make[1]: [Makefile:38608: all-recursive] Error 1 make[1]: Leaving directory '/tmp/.cache/aur/mpich/src/mpich-3.2.1/build' make: *** [Makefile:10337: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build mpich package(s)

jedbrown commented on 2018-05-10 03:51 (UTC)

@jbarnett Appending is intentional. Many people have both installed and /opt/mpich should not take precedence over /usr.

You should not need LD_LIBRARY_PATH because this package installs /etc/ld.so.conf.d/mpich.conf.

commented on 2018-04-21 14:10 (UTC)

For users who want to replace openmpi with mpich add "provides=('openmpi')" and "conflicts=('openmpi')" to your PKGBUILD. Also change "--prefix" to "/usr" in the configure part. Also remove any references to mpich.profile. Note that some packages may depend on openmpi libraries that mpich does not provide, so if you go this route you would need to rebuild them. For example, I had to rebuild arpack against mpich.

I'm also unsure if "--with-python" does anything. I can't find any documentation on that configure flag.

commented on 2018-02-24 20:42 (UTC)

mpich.profile is incomplete. You are actually appending (not prepending) the mpich path to PATH. So if you have openmpi installed as well, then its executable is found first. If you have trouble with libraries not being found, you need to set LD_LIBRARY_PATH in the profile.

Archange commented on 2018-02-08 14:23 (UTC)

I agree, though there have been huge progresses with the release of OpenMPI 3.0.

That being said I intend to provide both, but there is a lot of work toward that result. The easiest thing I could do currently is having both stacks (MPI + HDF, NetCDF, etc.) available but mutually exclusive. Would that suit everyone here?

We could still keep this package with a different name, like mpich-opt, for co-installability.

mizuchi commented on 2018-02-08 12:45 (UTC)

MPICH should be the default MPI provider in Arch, I guess. Many scientific applications poorly run with OpenMPI unlike MPICH.

jedbrown commented on 2016-05-02 18:13 (UTC)

@melkir The package provides /etc/profile.d/mpich.so to set the path. This is automatically executed by /etc/profile. I strongly discourage linking into /usr because it conflicts with openmpi and because it is not managed by the package manager. It sounds like you're executing your IDE in an environment that misses /etc/profile.

melkir commented on 2016-05-02 16:11 (UTC) (edited on 2016-05-02 16:14 (UTC) by melkir)

If you need to use mpich in your IDE you need to execute the following lines : su ln -sf /opt/mpich/lib/*.so /usr/lib/ ln -sf /opt/mpich/include/* /usr/include/ ln -sf /opt/mpich/bin/* /usr/local/bin/ If you prefer you can add to your path /opt/mpich/bin instead of linking /opt/mpich/bin to /usr/local/bin. I don't know if there is a better way to do that but maybe something like that should be included in the installation process !

jedbrown commented on 2015-11-02 18:59 (UTC)

@jadelord mpich.org is currently suffering NFS problems. The latest stable version has not been reverted.

jadelord commented on 2015-11-01 22:26 (UTC) (edited on 2015-11-01 23:25 (UTC) by jadelord)

It seems v3.1.4 has been removed. Gives a curl 404 error The latest stable release is v3.0: http://www.mpich.org/static/downloads/3.0/ Here is a working PKGBUILD: http://pastebin.com/fe6dSL3e

eleftg commented on 2015-03-19 14:15 (UTC)

An up-to-date (v3.1.4) PKGBUILD is available at http://pastebin.com/6MPfsg2B

bluerider commented on 2015-02-16 16:33 (UTC)

Updated to upstream 3.1.3; sorry for the long delay.

VonBirdie commented on 2014-03-02 21:25 (UTC)

I had problems with getting cmake to recognize the mpich package but this package seems to work with cmake (probably the fixed paths that does it that is mentioned earlier).

bluerider commented on 2013-10-30 22:43 (UTC)

@ramwoolf: I have finally replicated your error; I'm looking into it now.

bluerider commented on 2013-10-30 20:55 (UTC)

@ramwoolf : I launched a i686 instance of arch linux with virtualbox and was enable to replicate the error you are having. Can you give me more information such as the preceding lines before the error?

ramwoolf commented on 2013-10-29 06:21 (UTC)

@bluerider: Error is .../cpuid.h:39: Error: symbol `Lhwloc1' is already defined Similar problem from the first post. I looked into the cpuid.h, this is asm block.

bluerider commented on 2013-10-29 03:19 (UTC)

@ramwoolf : Which error are you getting?

ramwoolf commented on 2013-10-21 14:57 (UTC)

I have got the same error at i686. Does anybody know solution of this problem?

bluerider commented on 2013-07-12 01:32 (UTC)

@jedbrown : Added to the conflicts array, thanks a lot!

bluerider commented on 2013-07-12 01:31 (UTC)

@dlin : It places the files in directories I prefer (not /opt).

dlin commented on 2013-07-12 00:49 (UTC)

why create new? is it different then mpich in AUR?

jedbrown commented on 2013-07-10 20:45 (UTC)

This package conflicts with openmpi from extra.

bluerider commented on 2013-04-08 18:23 (UTC)

@jedbrown : I have been considering removing this package from the AUR, but the other mpich package places the files for mpich in directories I don't agree with.

jedbrown commented on 2013-04-06 23:19 (UTC)

Why does this package exist? The 'mpich' package is just a new release, and is backward-compatible with earlier releases. The project is called MPICH now (again).

jedbrown commented on 2013-04-04 12:57 (UTC)

@l0gic Why do you have '-fPIE -pie' in CFLAGS in the first place? There are many other things you could put in CFLAGS that would also break the build so I'm not inclined to add such a specific hack to work around such flags (that will also break many other packages) without a damn compelling reason.

l0gic commented on 2013-04-04 12:46 (UTC)

Could you replace export MPICHLIB_CFLAGS="CFLAGS" with export MPICHLIB_CFLAGS="${CFLAGS//-fPIE -pie}" (same for CXXFLAGS) in the next release? PIE breaks the build (obviously).

bluerider commented on 2013-03-28 19:14 (UTC)

@Omegalpha : Your error is confirmed in the single threaded compilation as well.

bluerider commented on 2013-03-28 18:55 (UTC)

@Omegalpha : I have confirmed your error via a multithreaded compilation on 32 bit arch linux virtualized by arch linux. I am now trying a single threaded compilation.

bluerider commented on 2013-03-28 17:02 (UTC)

I'll investigate your error by compiling it on a 32 bit virtual Arch machine in Virutalbox. Sorry for the late response.

commented on 2013-03-27 10:07 (UTC)

Sorry.Some error happened in my laptop (lenovo Y460) /home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/include/private/cpuid.h: Assembler messages: /home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/include/private/cpuid.h:39: Error: symbol `Lhwloc1' is already defined make[5]: *** [topology-x86.lo] Error 1 make[5]: Leaving directory `/home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/omega/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/omega/Downloads/mpich3/src/mpich-3.0.2' make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... it's i686 machine, i have successed in a i86_64 machine What can I do?

bluerider commented on 2013-03-10 06:19 (UTC)

This is the mpich3 implementation of the message passing interface. It is used for building distributed computing projects.

jedbrown commented on 2013-03-01 12:17 (UTC)

@Chrishas You need 'sowing' to build documentation. It's in makedepends now.

commented on 2013-03-01 01:09 (UTC)

When I makepkg the build process exits with the following: test -d /home/chris/Downloads/mpich/src/mpich-3.0.2/build/man/man3 || mkdir -p /home/chris/Downloads/mpich/src/mpich-3.0.2/build/man/man3 make mandoc-local make[1]: Entering directory `/home/chris/Downloads/mpich/src/mpich-3.0.2/build' DOCTEXTMAN src/mpi/attr/attr_delete.man-phony make[1]: *** [src/mpi/attr/attr_delete.man-phony] Error 1 make[1]: Leaving directory `/home/chris/Downloads/mpich/src/mpich-3.0.2/build' make: *** [mandoc] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

jedbrown commented on 2013-02-16 19:26 (UTC)

@Edgemaster Thanks. They changed the default target and I fixed it locally, but forgot to push. Updated now.

Edgemaster commented on 2013-02-16 18:42 (UTC)

manpages don't seem to be packaged, even though provision is made for them in the profile.d file.

doug commented on 2012-12-14 10:17 (UTC)

the process-core binding is broken, when I try to bind processes to cores as described here http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Process-core_Binding I get errors [proxy:0:0@embryo04] get_nbobjs_by_type (../../../../src/pm/hydra/tools/topo/hwloc/topo_hwloc.c:189): assert (nb % x == 0) failed [proxy:0:0@embryo04] handle_bitmap_binding (../../../../src/pm/hydra/tools/topo/hwloc/topo_hwloc.c:450): unable to get number of objects [proxy:0:0@embryo04] HYDT_topo_hwloc_init (../../../../src/pm/hydra/tools/topo/hwloc/topo_hwloc.c:527): error binding with bind "core" and map "(null)" [proxy:0:0@embryo04] HYDT_topo_init (../../../../src/pm/hydra/tools/topo/topo.c:60): unable to initialize hwloc [proxy:0:0@embryo04] launch_procs (../../../../src/pm/hydra/pm/pmiserv/pmip_cb.c:516): unable to initialize process topology [proxy:0:0@embryo04] HYD_pmcd_pmip_control_cmd_cb (../../../../src/pm/hydra/pm/pmiserv/pmip_cb.c:890): launch_procs returned error [proxy:0:0@embryo04] HYDT_dmxu_poll_wait_for_event (../../../../src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status [proxy:0:0@embryo04] main (../../../../src/pm/hydra/pm/pmiserv/pmip.c:210): demux engine error waiting for event [mpiexec@embryo04] control_cb (../../../../src/pm/hydra/pm/pmiserv/pmiserv_cb.c:201): assert (!closed) failed [mpiexec@embryo04] HYDT_dmxu_poll_wait_for_event (../../../../src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status [mpiexec@embryo04] HYD_pmci_wait_for_completion (../../../../src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:196): error waiting for event [mpiexec@embryo04] main (../../../../src/pm/hydra/ui/mpich/mpiexec.c:325): process manager error waiting for completion the 1.5 package for debian from here http://www.cebacad.net/files/mpich2/debian works fine on debian system

mrbit commented on 2012-05-24 19:16 (UTC)

ok. thanks

jedbrown commented on 2012-05-24 18:39 (UTC)

The 1.4.1 build system was broken and 1.5b1 is a beta which also had build system issues. I sent patches upstream and they were accepted, so they will be in the next release. I will update this package when 1.5 is released.

mrbit commented on 2012-05-24 17:55 (UTC)

update please...thanks

karabaja4 commented on 2012-04-11 19:21 (UTC)

Yeah, that seems right. So, it would be prudent to include openssh as a dependency.

thebodzio commented on 2012-04-02 23:39 (UTC)

@karabaja4: I think it uses ssh heavily in the course of “delegating” processes and communicating with them. Take a look at ps when running some program via mpirun, you'll find a bunch of ssh sessions with stdout redirected to originating host. Of course this is only a simple observation and the purpose of ssh may be different, but… I think it's quite reasonable to assume it is as described.

karabaja4 commented on 2012-03-29 15:44 (UTC)

For some reason this package needs openssh package, otherwise even the simplest multiprocess tasks executed with mpiexec give segmentation fault.

jedbrown commented on 2011-11-04 01:33 (UTC)

Update blocked on: http://trac.mcs.anl.gov/projects/mpich2/ticket/1543

jedbrown commented on 2011-09-11 21:15 (UTC)

@kkb110 That is a bug with the BLACS build system which the blacs-mpi package should work around. $ /opt/mpich2/bin/mpicc -show gcc -Wl,--hash-style=gnu -Wl,--as-needed -I/opt/mpich2/include -L/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt

kkimdev commented on 2011-09-11 18:41 (UTC)

I think compiling blacs-mpi https://aur.archlinux.org/packages.php?ID=23035 fails because of this. gfortran -lpthread -o /tmp/yaourt-tmp-kkb110/aur-blacs-mpi/src/BLACS/TESTING/EXE/xFbtest_MPI-LINUX-0 blacstest.o btprim_MPI.o tools.o -L/tmp/yaourt-tmp-kkb110/aur-blacs-mpi/src/BLACS/LIB -lblacsf77 -lblacs -lblacsf77 -Wl,-rpath,/opt/mpich2/lib/ -L/opt/mpich2/lib/ -lmpich -lssl -luuid -lpthread -lrt -ldl -lnsl -lrt /opt/mpich2/lib//libmpich.so: undefined reference to `MPL_trfree' /opt/mpich2/lib//libmpich.so: undefined reference to `MPL_env2str' ... ...

jedbrown commented on 2011-08-26 13:58 (UTC)

@ram http://trac.mcs.anl.gov/projects/mpich2/ticket/1150 You can edit the PKGBUILD to use MPD if you want the -gdb option, but Hydra is a better process manager in many ways.

ram commented on 2011-08-26 13:53 (UTC)

I miss the -gdb flag. Is it removed for some reason?

jedbrown commented on 2011-06-19 14:01 (UTC)

This update removes support for the MPD and gforker process managers since Hydra is plenty stable these days.

queenmedley commented on 2011-04-12 09:57 (UTC)

thanks jedbrown.. I uncommentted $LD_FLAGS and ...etc.. in makepkg.conf. and now I suceed in compiling..

jedbrown commented on 2011-04-10 17:38 (UTC)

Check your /etc/makepkg.conf, you're on your own if configuring with ifort instead of gfortran (but there should be a compiler flag to get compatible ELF formats).

queenmedley commented on 2011-04-10 13:48 (UTC)

when I execute makepkg, error occures. the error meassage is ---------------------------------------------------------------------------- checking whether Fortran 77 and C objects are compatible... no checking for file... file configure: error: **** Incompatible Fortran and C Object File Types! **** F77 Object File Type produced by "ifort " is : : ELF 64-bit LSB relocatable, x86-64, version 1 (GNU/Linux), not stripped. C Object File Type produced by "gcc -march=x86-64 -mtune=generic -O2 -pipe -O2" is : : ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped. ==> ERROR: A failure occurred in build(). Aborting... -------------------------------------------------------------------------------------- But just excuting "./configure" , nothing happens..everything is fine..then make as well. -------------------------------------------------------------------------------- checking whether Fortran 77 and C objects are compatible... yes checking for Fortran 77 name mangling... lower underscore --------------------------------------------------------------------------------- the diffence is "checking whether Fortran 77 and C objects are compatible..." "yes or no.."

jedbrown commented on 2010-12-26 18:51 (UTC)

Installing to /usr would make mpich2 conflict with openmpi which would be very bad because many users including myself use both. I removed RPATH, there are still warnings about hwloc which is a (tiny) bundled dependency, but mpich2 does not currently offer a way to use the system hwloc. Note that hwloc has an optional dependency on cairo, but mpich2 does not require that functionality. Finally, namcap says that gcc-fortran is not a real dependency, but it really is required since far too many MPI users need the fortran wrappers to function correctly.

td123 commented on 2010-12-26 00:18 (UTC)

Hi, thanks for the package! Some suggestions, after running the pkg through namcap, I got the following: http://pastie.org/private/97v2wtkz0dtaioudubwcva Can you consider installing to /usr instead of /opt? Also for the rpath warnings, there could be a disable-rpath option in the configure somewhere, otherwise it would be wise to use chrpath and remove the rpaths.

jedbrown commented on 2010-12-10 23:34 (UTC)

Since it's not just me hitting this, I updated the package with a patch to their configure script that fixes the problem.

doomguard88 commented on 2010-12-10 23:02 (UTC)

"edit PKGBUILD so that MPICH2LIB_LDFLAGS and LDFLAGS are both unset" can you elaborate on how to do that?? which line to edit?

jedbrown commented on 2010-11-25 14:14 (UTC)

There is a bug upstream which causes MPICH2LIB_LDFLAGS to be included in the wrapper, as would LDFLAGS. For a reason that I don't understand, the -Wl,--as-needed from /etc/makepkg.conf which goes into the MPICH2 wrapper compilers causes libstdc++ link errors for some mixed C++/Fortran programs on my machine. The workaround (as of 1.3.1-2) is to edit PKGBUILD so that MPICH2LIB_LDFLAGS and LDFLAGS are both unset. If others are seeing this problem, I can update the PKGBUILD with this workaround, but otherwise I would rather not ignore LDFLAGS. Until they fix the problem upstream, there is no way to build the MPICH2 libraries with desired LDFLAGS without putting them into the wrappers.

commented on 2010-10-29 23:07 (UTC)

Works for me, thanks. I did get this warning while building, though: WARNING: Package contains reference to $srcdir

jedbrown commented on 2010-10-29 21:07 (UTC)

Done, please report any problems.

commented on 2010-10-29 20:14 (UTC)

Oh, and an /etc/ld.so.conf.d/mpich2 would be really useful, too!

commented on 2010-10-29 20:13 (UTC)

Nope, no gfortran. It didn't occur to me how many people might need it, but obviously a lot of scientific code is still Fortran, and that's the segment mpich2 is aimed at!

jedbrown commented on 2010-10-28 20:23 (UTC)

@tam1138 Do you have gfortran installed? Looks like it should be made a dependency. I don't want to remove support for Fortran because lots of users need it. I'll add PKG_CONFIG_PATH, thanks.

commented on 2010-10-28 19:56 (UTC)

Also, it'd be swell if you could include an /etc/profile.d/mpich2 along these lines: export PATH=$PATH:/opt/mpich2/bin export MANPATH=$MANPATH:/opt/mpich2/man export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mpich2/lib/pkgconfig

commented on 2010-10-28 19:16 (UTC)

Configure fails because of Fortran nonsense: configure: error: Fortran 90 support requires compatible Fortran 77 support. To force the use of the Fortran 90 compiler for Fortran 77, do not use configure option --disable-f77, and set the environment variable F77 to the name of the Fortran 90 compiler, or $FC. If you do not want any Fortran support, use configure options --disable-f77 and --disable-fc. I added "--disable-f77 --disable-fc" to the configure options in the PKGBUILD, and it seems to work fine.

jedbrown commented on 2010-10-24 10:55 (UTC)

The soname has changed with version 1.3, you will need to rebuild all packages that depend on mpich2. Hydra is now the default process manager. MPD and gforker are still available if you launch with mpiexec.{mpd,gforker}, but they should not be necessary.

jedbrown commented on 2010-10-19 10:17 (UTC)

New dependency is on python2. This version (1.2.1p1-2) has one other change you should be aware of. MPICH2 historically injects it's build-time CFLAGS into the mpicc wrapper, and similar for other wrappers. Since the default /etc/makepkg.conf contains optimization (-O2), /opt/mpich2/bin/mpicc (with no optimization flags) was still compiling with optimization. This package version does MPICH2LIB_CFLAGS="$CFLAGS"; unset CFLAGS so that the wrappers no longer include optimization flags. The mpich2 library is still built with whatever optimization was in CFLAGS. This new behavior is consistent with other wrapper compilers (e.g. /usr/bin/mpicc from openmpi) and friendlier for debugging because you don't have to always remember to use -O0.

commented on 2010-10-19 07:34 (UTC)

Need to use --with-python=python2 instead of --with-python=python in configure line because of python migration.

jedbrown commented on 2010-08-30 12:42 (UTC)

The trouble is that MPI applications need to link a specific MPI (only the API is standardized, not the ABI). Even if the ABI was standardized, this would make the implementations conflict, which isn't nice because most developers want to have at least two implementations installed concurrently. The solution we're living with now is to that Open MPI is the blessed implementation installed in /usr, MPICH2 is installed at /opt/mpich2 and packages built against mpich2 are usually named foo-mpich2.

domanov commented on 2010-08-30 11:35 (UTC)

Dear packager, I think it would be of use if each mpi implementation (openmpi, mpich2, ...) contains the "provides=('mpi')" array. That way a lot of packages depending on MPI infrastructure and not on the specific flavor would be much easier to mantain. Or would it bring a huge matter of conflicts I cannot see right now? I post this same comment in the openmpi AUR thread. Cheers, domanov