Package Details: mumps 5.1.2-2

Git Clone URL: (read-only)
Package Base: mumps
Description: Sparse solver library using Gaussian elimination
Upstream URL:
Licenses: custom
Conflicts: mumps-par, mumps4
Provides: mumps
Submitter: mickele
Maintainer: heitzmann
Last Packager: heitzmann
Votes: 8
Popularity: 0.804881
First Submitted: 2009-04-05 16:37
Last Updated: 2018-03-20 17:26

Latest Comments

heitzmann commented on 2018-03-20 17:26

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

Viech commented on 2018-03-19 19:05

@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

@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

@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

@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

@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

@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

@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

@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

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

All comments