Package Details: mumps 5.1.2-2

Git Clone URL: https://aur.archlinux.org/mumps.git (read-only)
Package Base: mumps
Description: Sparse solver library using Gaussian elimination
Upstream URL: http://mumps.enseeiht.fr
Licenses: custom
Conflicts: mumps-par, mumps4
Provides: mumps
Submitter: mickele
Maintainer: heitzmann
Last Packager: heitzmann
Votes: 8
Popularity: 0.421663
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 libdmumps_seq.so, 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 http://dl.viech.name/sdpa2/PKGBUILD does pass the check for MUMPS and compiles successfully, but launching sdpa outside of /usr/lib gives »sdpa: error while loading shared libraries: ./libdmumps_seq.so: cannot open shared object file: No such file or directory«. ldd gives me

./libdmumps_seq.so => not found ./libmumps_common_seq.so => not found ./libpord_seq.so => not found libmpiseq.so => /usr/lib/libmpiseq.so

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 libmpiseq.so 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 Makefile.inc? 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 Makefile.inc, 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 http://dl.viech.name/sdpa/PKGBUILD 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...)

Viech commented on 2018-03-06 22:23

Hello, I am encountering the same issue as reported under https://sourceforge.net/p/sdpa/discussion/1393613/thread/1a6d8897/ when using this MUMPS package with my self-compiled SDPA (planning to create a package for the latter). Since your package ships its own Makefile.inc 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 Makefile.inc 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

@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

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

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

gdolle commented on 2016-05-29 13:32

Hi, I got this error since zlib 1.2.8
----
/usr/lib/libscotch.so : référence indéfinie vers « gzwrite »
/usr/lib/libscotch.so : référence indéfinie vers « gzsetparams »
/usr/lib/libscotch.so : référence indéfinie vers « gzclose »
/usr/lib/libscotch.so : référence indéfinie vers « gzdopen »
/usr/lib/libscotch.so : 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
https://gist.github.com/gdolle/7e1b15abe12f983e340ba215e667f337

mickele commented on 2015-08-07 18:30

@hyperelastic
Try mumps4

hyperelastic commented on 2015-08-04 22:25

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

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

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

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

@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

@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

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

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

metis4 is missing in the deps

mickele commented on 2014-12-24 11:08

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

mickele commented on 2014-12-14 10:45

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

eleftg commented on 2014-10-14 11:14

Indeed. Problem solved.

Thanks!

mickele commented on 2014-10-13 18:40

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

eleftg commented on 2014-10-06 14:51

Any news regarding the error?

eleftg commented on 2014-09-26 11:30

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/libmpi_usempi_ignore_tkr.so
/usr/lib/openmpi/libmpi_usempi_ignore_tkr.so.0
/usr/lib/openmpi/libmpi_usempi_ignore_tkr.so.0.0.0
/usr/lib/openmpi/libmpi_usempif08.so
/usr/lib/openmpi/libmpi_usempif08.so.0
/usr/lib/openmpi/libmpi_usempif08.so.0.5.0

???

mickele commented on 2014-08-31 20:26

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 http://mumps.enseeiht.fr/index.php?page=faq#18.
Symilar problem for scotch_esmumps (look at http://www.code-aster.org/forum2/viewtopic.php?id=18497).

eolianoe commented on 2014-08-27 19:23

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

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

heitzmann commented on 2014-06-19 00:41

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

@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

I had to change the Makefile.inc and PKGBUILD to make it compile. If some are interested,
https://github.com/dolleg/AUR/tree/master/lib/mumps/4.10.0

gdolle commented on 2013-08-03 14:27

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 ?

gdolle commented on 2013-08-03 14:25

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 ?

gdolle commented on 2013-08-03 14:25

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 ?

gdolle commented on 2013-08-03 14:24

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 ?

gdolle commented on 2013-08-03 14:24

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 ?

gdolle commented on 2013-08-03 14:23

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 ?

gdolle commented on 2013-08-03 14:16

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

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

foobarrior commented on 2013-03-27 06:15

Update your dependencies!
-change mpich2 to mpich
-change parmetis-mpich2 to parmetis-mpich

Anonymous comment on 2012-11-20 19:16

@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

check out: https://github.com/gauteh/arch/tree/master/mumps and https://github.com/gauteh/arch/tree/master/scotch_esmumps for version that doesnt have nodewnd problem.

Anonymous comment on 2012-03-01 00:38

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

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