Package Details: mumps 5.5.0-1

Git Clone URL: (read-only, click to copy)
Package Base: mumps
Description: Sparse solver library using Gaussian elimination
Upstream URL:
Keywords: computing scientific
Licenses: custom
Conflicts: mumps-par, mumps4
Submitter: mickele
Maintainer: MartinDiehl
Last Packager: MartinDiehl
Votes: 14
Popularity: 0.24
First Submitted: 2009-04-05 16:37 (UTC)
Last Updated: 2022-04-24 17:29 (UTC)

Pinned Comments

MartinDiehl commented on 2020-05-15 20:09 (UTC)

The sequential version is disabled, according to the manual it is only meant for systems without a MPI compiler but openmpi is a prerequisite. If there is any need for the sequential version, it can be enabled again.

Latest Comments

Xwang commented on 2021-04-22 07:26 (UTC) does not pass the validity check.

entshuld commented on 2021-04-20 21:16 (UTC) (edited on 2021-04-20 23:03 (UTC) by entshuld)

diff --git a/PKGBUILD b/PKGBUILD
index 9335c08..86fe803 100644
@@ -48,6 +48,9 @@ package(){
   install -m 755 -d "${pkgdir}/usr/share/doc/${pkgname}/examples"
   cd "${srcdir}/MUMPS_${pkgver}/examples"
   install -m 644 * "${pkgdir}/usr/share/doc/${pkgname}/examples"
+  install -m 644 "${srcdir}/MUMPS_${pkgver}/" "${pkgdir}/usr/share/doc/${pkgname}/examples"
+  sed -i 's_\(topdir =\).*_\1 /usr_g; s-.*\(\)-include' "${pkgdir}/usr/share/doc/${pkgname}/examples/Makefile"
+  sed -i 's-\(LIBEXT[[:space:]]*=[[:space:]]*\)\.a-\' "${pkgdir}/usr/share/doc/${pkgname}/examples/"

   # Install license
   install -D -m644 "${srcdir}/MUMPS_${pkgver}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

MartinDiehl commented on 2020-05-15 20:09 (UTC)

The sequential version is disabled, according to the manual it is only meant for systems without a MPI compiler but openmpi is a prerequisite. If there is any need for the sequential version, it can be enabled again.

xantares commented on 2020-05-15 13:20 (UTC) (edited on 2020-05-15 13:20 (UTC) by xantares)

It wont build anymore unless I add -fallow-argument-mismatch fortran flag to OPTF, this is due to the gcc 10 upgrade

adsun commented on 2019-11-26 14:15 (UTC)

This requires the package gcc-fortran added to makedepends to build in a clean chroot without error.

haawda commented on 2018-12-23 00:01 (UTC) (edited on 2018-12-23 05:29 (UTC) by haawda)

Please remove the versioned dependency to scotch. The scotch PKGBUILD does not provide it.

heitzmann commented on 2018-03-20 17:26 (UTC)

@Viech thaks! I've updated the PKGBUILD to include those links.

Viech commented on 2018-03-19 19:05 (UTC) (edited on 2018-03-19 19:06 (UTC) by Viech)

@heitzmann, I now suspect that the issue is in the SPDA linking process as opposed to within your mumps-seq package. However, I found a related small issue with your package: It is not shipping symlinks to the shared object files that end in .so (it ships only symlinks ending in .so.5). This is not the cause of my problem though, as Pacman/yaourt creates these symlinks on the fly (but they end up as stray files that do not belong to any package). Thank you for your help so far!

heitzmann commented on 2018-03-19 12:07 (UTC)

@Viech, I'm no expert either, but it seems to me that spda is looking for the libraries, etc. in the current dir. During compilation that comes from the "-L." argument, whereas these libraries should have been found in /usr/lib (from "-L/usr/lib").

Check /usr/lib to make sure the libraries are there. If not, your mumps-seq installation needs some fixing. Also make sure the libraries are NOT available in the compilation folder when building spda, because you want the system versions.

Viech commented on 2018-03-18 13:10 (UTC)

@heitzmann, I installed your mumps-seq package and the updated PKGBUILD at does pass the check for MUMPS and compiles successfully, but launching sdpa outside of /usr/lib gives »sdpa: error while loading shared libraries: ./ cannot open shared object file: No such file or directory«. ldd gives me

./ => not found ./ => not found ./ => not found => /usr/lib/

During compilation of SDPA I see »… -L. -lsdpa -L/usr/lib -ldmumps_seq -lmumps_common_seq -lpord_seq -lmpiseq …«. There are no files matching »dmumps« anywhere in the SDPA source tree.

Any idea why this is happening now but not with your mumps package? I haven't seen anything like this before and I'm rather clueless, in particular because the reference to is correct. The good news is that when I call sdpa from inside /usr/lib it is working just fine, so using mumps-seq would fix my original issue.

heitzmann commented on 2018-03-18 11:51 (UTC)

@Viech The change you're proposing seem to be included in $INCSEQ, so there is no need to add it to $OPTF.

The issue seems to be that $INCSEQ is not enabled because this package builds a parallel version of mumps (lines 160-162 and 165-167).

Does it work if you change to a sequential version?

Viech commented on 2018-03-17 16:15 (UTC)

@heitzmann, have you made up your mind about an adjustment to your My release of the sdpa package in its current form depends on it; otherwise I would try to fall back to getting the outdated MUMPS shipped with SDPA to compile, which may lead to a package conflicting with yours.

Viech commented on 2018-03-08 16:19 (UTC)

@heitzmann, in your, replacing »OPTF = -DALLOW_NON_INIT ${CFLAGS} -fPIC« with »OPTF = -I../libseq -DALLOW_NON_INIT ${CFLAGS} -fPIC« (in the spirit of the workaround proposed in the SourceForge thread) does fix my issue with SDPA. You might want to check if other applications using MUMPS are negatively affected by this before updating as I can't tell if there can be any side-effects.

heitzmann commented on 2018-03-08 15:39 (UTC)

@Viech I see... I'm not sure how to fix this issue then. If you find a way by changing this package's Makefile, let me know and I can update the AUR version.

Viech commented on 2018-03-07 14:39 (UTC)

@heitzmann, this is exactly what I do to make sure that your package is used instead of the MUMPS sources that SDPA downloads otherwise (I pass »--with-mumps-libs="-ldmumps -lmumps_common -lesmumps -lmpiseq -lgfortran -lscotch -lscotcherr -lmetis -lpord -llapack"« to make the ./configure check for an existing MUMPS pass). I verified that ./configure indeed finds MUMPS and no download is attempted. To be extra sure that the file you mention cannot be the cause, I now delete mumps/Makefile in prepare().

If you would want to have a look, my package is at and »sdpa -o /tmp/example1.result -dd /usr/share/sdpa/example/example1.dat« will throw »ERROR in MPI_ALLREDUCE, DATATYPE= 7« on my end.

Since SDPA downloads MUMPS 4.10 sources if it does not find a working library I also tested with your mumps4 package (and »-lmetis-4« instead of »-lmetis«). Unfortunately the result is the same.

heitzmann commented on 2018-03-07 11:41 (UTC)

@Viech, as I understand, the issue you pointed is with the Makefile for mumps included in the SDPA package itself (check mumps directory in the source).

In any case, I'd recommend you try to avoid recompiling mumps just for your package by using the configure options: --with-mumps-include="-I/usr/include" --with-mumps-libs="-L/usr/lib -ldmumps -lmumps_common -lpord -lmpiseq" (or something similar...)

Viech commented on 2018-03-06 22:23 (UTC)

Hello, I am encountering the same issue as reported under when using this MUMPS package with my self-compiled SDPA (planning to create a package for the latter). Since your package ships its own and the issue seems to be inside that file, I wonder if you could fix it on your end somehow? Unfortunately, adding the proposed line to your did not result into successful compilation right away, and I do not know how to make it work.

heitzmann commented on 2017-06-20 13:29 (UTC)

@capitalaslash Sure, if you could paste it somewhere and link it here it would be great! Thanks!

capitalaslash commented on 2017-06-20 13:20 (UTC)

I have an updated PKGBUILD for 5.1.1 with real shared library compilation, let me know if you want it.

heitzmann commented on 2016-05-31 12:49 (UTC)

Thanks @gdolle! I've included your fix straight into Let me know if the problem persists.

gdolle commented on 2016-05-29 13:32 (UTC)

Hi, I got this error since zlib 1.2.8 ---- /usr/lib/ : référence indéfinie vers « gzwrite » /usr/lib/ : référence indéfinie vers « gzsetparams » /usr/lib/ : référence indéfinie vers « gzclose » /usr/lib/ : référence indéfinie vers « gzdopen » /usr/lib/ : référence indéfinie vers « gzread » collect2: erreur : ld a retourné 1 code d'état d'exécution ---- I don't know if it comes from my install, but if someone has the same problem, adding zlib linking "-lz" should solve the problem. See this patch

mickele commented on 2015-08-07 18:30 (UTC)

@hyperelastic Try mumps4

hyperelastic commented on 2015-08-04 22:25 (UTC)

Doesnt build. In turn, unable to install aster. The message looks like this: libcmumps.a(cana_aux_par.o): In function `__cmumps_parallel_analysis_MOD_cmumps_assemble_top_graph': ... libcmumps.a(cfac_asm_master_m.o):cfac_asm_master_m.F:(.text+0x74e5): more undefined references to `__stack_chk_fail_local' follow

mickele commented on 2015-02-28 07:05 (UTC)

I tried compiling with metis-4, but it stopped with an error. It seems mumps-5 requires metis-5.

fhr commented on 2015-02-27 23:31 (UTC)

You can use Metis 4.x or lower by compiling with -Dmetis4, ParMetis 3.2.0 or lower with -Dparmetis3. So you could have a mumps-5_metis-4 package I guess...

mickele commented on 2015-02-27 18:28 (UTC)

mumps-5 requires metis-5, so I had to create another package (mumps4) to link with code-aster (that requires metis-4).

eleftg commented on 2015-02-19 16:35 (UTC)

@eolianoe: Indeed. Those extra'pkg' in the install paths are redundant :-) However mine built fine with 16 procs. Weird... (timing issue perhaps?)

eolianoe commented on 2015-02-19 08:31 (UTC)

@mickele: at line 37 and 50 you have an additional 'pkg' which should not be here. And the package failed to build with more than one core so maybe you should add a '-j1' to the make command.

mickele commented on 2015-01-12 21:19 (UTC)

4.10.0-6 Added metis4 dep. It isn't necessary to rebuild the package.

sarah.j commented on 2015-01-07 08:47 (UTC)

metis4 is missing in the deps

mickele commented on 2014-12-24 11:08 (UTC)

I removed linkage to parmetis, now (4.10.0-5) links only to metis-4.

mickele commented on 2014-12-14 10:45 (UTC)

Changed because of relocation of scotch_esmumps5 relocation of header files (4.10.0-4).

eleftg commented on 2014-10-14 11:14 (UTC)

Indeed. Problem solved. Thanks!

mickele commented on 2014-10-13 18:40 (UTC)

@eleftg Sorry for the delay, but at last I should have solved your issue.

eleftg commented on 2014-10-06 14:51 (UTC)

Any news regarding the error?

eleftg commented on 2014-09-26 11:30 (UTC)

make[1]: Entering directory '/home/george/aur-builds/mumps/src/MUMPS_4.10.0/examples' mpif77 -o ssimpletest -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fPIC ssimpletest.o ../lib/libsmumps.a ../lib/libmumps_common.a -L/usr/lib -lparmetis-3 -lmetis-4 -L../PORD/lib/ -lpord -L/usr/lib -lptesmumps -lptscotch -lptscotcherr -lscotchmetis -lscotch -lscalapack -llapack -L/usr/lib/openmpi -lmpi_mpifh -lmpi_usempi -lmpi -ldl -lhwloc -lblas -lpthread /usr/bin/ld: cannot find -lmpi_usempi collect2: error: ld returned 1 exit status Makefile:28: recipe for target 'ssimpletest' failed make[1]: *** [ssimpletest] Error 1 make[1]: Leaving directory '/home/george/aur-builds/mumps/src/MUMPS_4.10.0/examples' Makefile:42: recipe for target 'sexamples' failed make: *** [sexamples] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Trying to locate libmpi_usempi the results are the following: locate mpi_usempi /usr/lib/openmpi/ /usr/lib/openmpi/ /usr/lib/openmpi/ /usr/lib/openmpi/ /usr/lib/openmpi/ /usr/lib/openmpi/ ???

mickele commented on 2014-08-31 20:26 (UTC)

I added parmetis3 and scotch_esmumps5 in AUR. I created these two packages because it seems mumps-4.10 doesn't work well with parmetis-4. Look at Symilar problem for scotch_esmumps (look at

eolianoe commented on 2014-08-27 19:23 (UTC)

LIBPAR have been modified, but why did you change the depencies to parmetis3 and scotch_esmumps5 whose don't exist in the AUR ?

eolianoe commented on 2014-08-16 19:46 (UTC)

Flagged out-of-date because LIBPAR need to be changed in

heitzmann commented on 2014-06-19 00:41 (UTC)

For me the error seemed to be that the openmpi fortran lib is not libmpi_f77, but limmpi_mpifh and libmpi_usempi, so I just replaced it on the Makefile (line 77): LIBPAR = $(SCALAP) -L/usr/lib/openmpi -lmpi_mpifh -lmpi_usempi -lmpi -ldl -lhwloc

blixawillbargeld commented on 2014-05-21 20:08 (UTC)

@Gug: thanks for your PKGBUILD, did work for me too. AUR Version gives me an error as well.

gdolle commented on 2013-08-10 15:34 (UTC)

I had to change the and PKGBUILD to make it compile. If some are interested,

gdolle commented on 2013-08-03 14:16 (UTC)

I got a conflict between scotch_esmumps and ptscotch (It seems that scotch_esmumps already provide ptscotch so ptscotch>5.17 might not be required) Someone can confirm ?

foobarrior commented on 2013-03-28 11:33 (UTC)

ledomi, do foolowing: rm /usr/include/scotch/*metis*

commented on 2012-11-20 19:16 (UTC)

@plutus I have the same problem, did you find a solution? thanks @gauteh I tried to install from your link but I had the error any idea? thanks make[1]: Entering directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0' (cd src ; make s) make[2]: Entering directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0/src' make ARITH=s mumps_lib make[3]: Entering directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0/src' /opt/mpich2/bin/mpicc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -I/opt/mpich2/include -I../include -DAdd_ -I../PORD/include/ -I/usr/include/scotch -Dscotch -Dmetis -Dpord -Dptscotch -Dparmetis -c mumps_orderings.c -o mumps_orderings.o In file included from mumps_orderings.h:100:0, from mumps_orderings.c:54: /opt/mpich2/include/parmetis.h:33:4: error: #error "Incorrect user-supplied value fo IDXTYPEWIDTH" /opt/mpich2/include/parmetis.h:42:4: error: #error "Incorrect user-supplied value fo REALTYPEWIDTH" /opt/mpich2/include/parmetis.h:66:14: error: unknown type name ‘idx_t’ .... make[3]: *** [mumps_orderings.o] Error 1 make[3]: Leaving directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0/src' make[2]: *** [s] Error 2 make[2]: Leaving directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0/src' make[1]: *** [mumps_lib] Error 2 make[1]: Leaving directory `/home/julien/library/builds/arch-master2/mumps/src/MUMPS_4.10.0' make: *** [s] Error 2

gauteh commented on 2012-09-23 12:04 (UTC)

check out: and for version that doesnt have nodewnd problem.

commented on 2012-03-01 00:38 (UTC)

got this error: any idea? /opt/mpich2/bin/mpif77 -Dintel_ -DALLOW_NON_INIT -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -I/opt/mpich2/include -I. -I../include -c ssimpletest.F /opt/mpich2/bin/mpif77 -o ssimpletest -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include -I/opt/mpich2/include ssimpletest.o ../lib/libsmumps.a ../lib/libmumps_common.a -L/opt/mpich2/lib -lparmetis -lmetis -L../PORD/lib/ -lpord -L/usr/lib -lesmumps -lptscotch -lptscotcherr -lscalapack -llapack -lblacs -lblacsf77 -lblacs -L/opt/mpich2/lib/ -lmpich -lf77blas -latlas -lpthread ../lib/libsmumps.a(smumps_part2.o): In function `smumps_195_': smumps_part2.F:(.text+0x200ff): undefined reference to `metis_nodewnd_' collect2: ld returned 1 exit status make[1]: *** [ssimpletest] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-ste/aur-mumps/src/MUMPS_4.9.2/examples' make: *** [sexamples] Error 2

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

I think we should use ptscotch-mpich2 instead of ptscotch for dependency