Arch Linux User Repository

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.

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

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

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

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

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

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

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

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

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

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