Package Details: mpich 3.4.1-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: 85
Popularity: 0.021007
First Submitted: 2012-12-31 21:25
Last Updated: 2021-01-29 03:51

Latest Comments

1 2 3 4 5 6 ... Next › Last »

RonObvious commented on 2021-01-09 15:45

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

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

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

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

deep_thought commented on 2020-05-18 07:55

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

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

@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.

Anonymous comment on 2018-04-21 14:10

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.

Anonymous comment on 2018-02-24 20:42

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

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.