Package Details: mumps 5.2.1-4

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
Provides: mumps
Submitter: mickele
Maintainer: MartinDiehl
Last Packager: MartinDiehl
Votes: 14
Popularity: 0.165163
First Submitted: 2009-04-05 16:37
Last Updated: 2020-03-04 05:31

Latest Comments

1 2 3 4 5 6 Next › Last »

adsun commented on 2019-11-26 14:15

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

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

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.