Package Details: scotch 6.0.4-1

Git Clone URL: (read-only)
Package Base: scotch
Description: Software package and libraries for graph, mesh and hypergraph partitioning, static mapping, and sparse matrix block ordering. This is the all-inclusive version (MPI/serial/esmumps).
Upstream URL:
Licenses: custom:CeCILL-C
Conflicts: ptscotch-openmpi, scotch_esmumps, scotch_esmumps5
Provides: ptscotch, ptscotch-openmpi, scotch_esmumps, scotch_ptesmumps
Submitter: None
Maintainer: saxonbeta
Last Packager: eleftg
Votes: 25
Popularity: 0.212131
First Submitted: 2006-11-07 17:51
Last Updated: 2015-07-05 22:26

Dependencies (3)

Required by (9)

Sources (1)

Latest Comments

LWhitson2 commented on 2015-08-25 20:23

I'm sorry guys. I did not even realize I was still the owner of this package. I haven't been using Arch for a year or so now. I'll release it for someone else.

eleftg commented on 2015-08-25 19:42


These extra compression options provide functionality that may be useful to other users. Ideally, I would like to provide them as optional dependencies but so far I couldn't find a way (they need to be present at link time).

Correct me if I'm wrong, but I think that the current AUR packages depending upon scotch succesfully link against -lbz2 without a big fuss as to the amount of patches needed.

getzze commented on 2015-08-19 16:28

Is it possible to remove the bzip2 dependency, including the seds to include -DCOMMON_FILE_COMPRESS_GZ ? It requires a lot of patches to other packages where scotch is a dependency (basically to link with -lbz2).

valandil commented on 2015-03-10 14:05

Sorry. I accidentally pressed "Flag package out-of-date" instead of "Notify of new comments".

eleftg commented on 2015-03-10 08:23

Thanks. Next time, please don't flag as out-of-date. The fact that curl suddenly became picky about SSL certificates has nothing to do with the "out-of-date"-ness of the package. The package used to work just fine up to a certain moment.

valandil commented on 2015-03-09 19:45

I had to remove the "s" from source=("https://..."), as curl complained: "curl: (60) SSL certificate problem: unable to get local issuer certificate". Cheers.

keepitsimpleengr commented on 2015-02-21 16:20

Your guess is correct and I am using yaourt.
Now successfully compiled
Thnk you for your assistamce.

eleftg commented on 2015-02-20 23:43

@keepitsimpleengr: This output seems to agree with my initial guess. The package builds just fine. Then it proceeds with the tests but apparently you'are using an AUR helper not being able to send a key stroke in order to conclude the test suite. Have you tried pressing any key at that stage?

Anyway, we can easily verify the above theory, if you edit the PKGBUILD and comment the check() function (lines 56-61). This way you skip the test suite and just install the whole thing right after building.

keepitsimpleengr commented on 2015-02-20 21:48


eleftg commented on 2015-02-20 17:25


Educated guess (without having any data so far):

After compilation the check() function launches the tests, during which you might be required to press any key in order to further advance (Waiting for key press...)

eleftg commented on 2015-02-20 17:17

Are you sure this is the correct pastebin link?

Operating System Version:
Ubuntu 14.04 LTS (64 bit) [Xubuntu]
Kernel Name: Linux
Kernel Version: 3.13.0-27-generic

Can you post the output of makepkg?

keepitsimpleengr commented on 2015-02-20 17:11

scotch hanging during compilation. termout @
Linux KISE-005 3.18.7-2-ck #1 SMP PREEMPT Sat Feb 14 17:57:17 EST 2015 x86_64 GNU/Linux

mickele commented on 2015-02-19 08:44

I confirm that this version of the PKGBUILD (6.0.3-5) requires bzip2 at runtime. Building code-aster I had to add -lbz2 to the linking options.

eleftg commented on 2015-02-19 08:39

Fixed. I have some questions on this issue though. Probably I don't understand the way this dependency works...

It's not strictly needed for scotch's functionality unless you define -DCOMMON_FILE_COMPRESS_BZ2. So that's why I included it as optional.

However, if it's not there during build time, it doesn't build (-lbz2 linking flag). That's why I included it as makedepends.

And now you are telling me that even during runtime its absence causes problems... How? I mean... we are using a library that has a few extra symbols defined. That's ok as long as we don't make calls to functions that use these symbols. In that case we would be required to have bzip2 installed.

I'm probably missing something

eolianoe commented on 2015-02-19 08:23

@eleftg: after some tests it seems that you can't use scotch if you do not have bzip2 installed, so it should not be an optional dependency.

eleftg commented on 2015-02-19 07:29


-- Removed scotch_esmumps5 from provides
-- Removed -DSCOTCH_PTHREAD right before building the MPI versions

eolianoe commented on 2015-02-16 11:49

* yes, you should keep ptscotch-openmpi until the depends arrays of the other package are updateed,
* according to, mumps could depend on scotch v6.0.1, and the mumps package should be update to depend to this new version of scotch,
* you should ask for merge request rather than deletion in order to keep comments and votes,
* for bzip2 I do not have any idea on that, maybe a more experienced user ofo scotch could answer.

eleftg commented on 2015-02-16 09:57

@ eolianoe: Thank you very much. I (almost) entirely adopted your PKGBUILD :-) "Almost" because:

-- indeed, ptscotch-mpich2 is not provided. But...
-- ptscotch-openmpi is provided (since it's ptscotch built with openmpi :-) ). And if i remove it from provides=() i'm forced to uninstall openfoam.
-- scotch_esmumps5 is indeed NOT provided but if i remove it, i'm forced to uninstall mumps.
-- both mumps and openfoam build perfectly fine with this new version of scotch. So it can be considered as a drop-in replacement for the other *scotch* versions.
-- Meanwhile I filed requests of deletion for all other scotch packages as advised in
-- also enabled an optional dependency: bzip2 (which unfortunately will also constitute a make dependency for scotch and any project depending on it, however i tried both openfoam and mumps by adding -lbz2 and they built fine).

I would appreciate your feedback on the above issues.

myles commented on 2015-02-15 21:03

I've orphaned in case anyone here is interested in maintaining it

myles commented on 2015-02-15 21:02

I've orphaned [[][scotch_esmumps]] in case anyone here is interested in maintaining it

eolianoe commented on 2015-02-15 19:16

@eleftg: you should not provide ptscotch-mpich2, ptscotch-openmpi, and scotch_esmumps5 as there are different "projects" the first are built with different MPI and the last is a legacy version, but they should stay in the conflicts array.
You should rather provide scotch, ptscotch, and scotch-esmumps as this is that your package really provides.
Here is a proposal for an update PKGBUILD (which use 'make install'):

eleftg commented on 2015-02-14 08:05

Well... yes, sure. Why not?

mickele commented on 2015-01-29 08:17

I can rename gpart to something like gpart-scotch.
What do you think about this?

eleftg commented on 2015-01-28 22:51

this package conflicts with gpart (

The reason is an executable with identical name: /usr/bin/gpart

mickele commented on 2014-12-14 10:46

Headers relocated in /usr/include/scotch, like in scotch. (5.1.12b-4)

mickele commented on 2014-12-12 22:23


I changed the PKGBUILD according to you suggestion.

PS: added line is options=('!makeflags') ;-)

saxonbeta commented on 2014-12-10 20:34

Hi, when i try to compile the package I get the following error:

make[2]: *** There is no rule to build the target ''

In my makepkg.conf I have the option MAKEFLAGS="-j4". After I have removed it, the package compiles fine. I think the line:
should be added to the PKGBUILD.

gucong commented on 2014-02-18 12:45

openmpi in archlinux is not built with thread support (See, but this package is built with -DSCOTCH_PTHREAD. This will result in errors in openfoam like the following:

ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE

A workaround is to add the following into build()

sed -i "s,-DSCOTCH_PTHREAD,,g"

jedbrown commented on 2014-01-26 17:54

@jdarch added option staticlibs. Is there a low-volume feed for PKGBUILD changes that packagers should watch?

jdarch commented on 2014-01-26 15:11

The default makepkg options will remove .a libs from the package, so eventually no lib will be in the package by default

Raptorista commented on 2013-10-07 16:06

Solved adding
export MAKEFLAGS="-j1"

According to this

Please update PKGBUILD.

Raptorista commented on 2013-10-07 16:02

I'm trying to compile but I get this error:
«no rule specified for target «», needed bt «main_esmumps». Stop.»
[translated from my language on the fly].

This is probably related to recent improvements.
Any hint? :)

myles commented on 2013-08-11 17:06

Gug, I have made those two improvements, thanks.

gdolle commented on 2013-08-05 10:19

And maybe copy esmumps.h and *esmumps*.so to the install prefix directory as it is not done by make install. (scotch bug ??)

gdolle commented on 2013-08-05 09:06

Hi, the libraries "" and "" are missing and required by mumps. It's not precised in the Install note, but I think we should add

make esmumps
make ptesmumps

to the pkgbuild.

Anonymous comment on 2013-05-19 14:51

Sorry for double post but fixed by symlinking

# ln -s /usr/lib/openmpi/ /usr/lib

Anonymous comment on 2013-05-19 14:46

I can't build this :

./ptdummysizes library_pt.h ptscotch.h
./ptdummysizes: error while loading shared libraries: cannot open shared object file: No such file or directory
make[2]: *** [ptscotch.h] Errore 127

but openmpi is installed. Could someone help me to figure this out ?

coincoin commented on 2013-05-03 14:09

I have uninstalled gpart and the installation is good. How can we avoid this ? gpart is part of extra/

coincoin commented on 2013-05-03 14:07

myles:Thanks I am having this error
/usr/bin/gpart is owned by gpart 0.1h-5

myles commented on 2013-03-13 01:47

coincoin: what does this show?
sudo pacman -Qo /usr/bin/gpart

coincoin commented on 2013-03-09 20:57

Have this error :
error: failed to commit transaction (conflicting files)
scotch_esmumps: /usr/bin/gpart exists in filesystem

jedbrown commented on 2013-03-03 00:20

@dibanez Okay, updated this and ptscotch-openmpi.

Anonymous comment on 2013-03-02 23:20

I ran into the issue described in the second paragraph of the
3) Compilation
section of scotch_6.0.0_esmumps/INSTALL.txt

Adding the following line to PKGBUILD worked for me, and should
be fine as long as mpicc doesn't cross-compile:

sed -i "/CCD/ c CCD\t\t= ${_prefix}/bin/mpicc"

myles commented on 2013-02-15 15:02

Headers now install to /usr/include instead of /usr/include/scotch.

LWhitson2 commented on 2013-02-02 02:40

@CAVT Yes, I know of this problem but do not have an answer at this time. I am an OpenFOAM user myself and don't really know what to do. I would suggest you do a developmental install using the OF packaged scotch for the time being.

CAVT commented on 2013-02-02 01:48

@LWhitson: Thank you very much for your concern :). However, I'm facing an issue, and it's that both this package and the ptscotch-openmpi package try to install equally-called headers in the /usr/include/scotch folder. Have you faced that problem? Is there a workaround? Just to add, both packages compile perfectly, the problem appears when the final installation is to be made and pacman complaints.

jedbrown commented on 2013-02-01 17:20

... and even if this works, you should still ask upstream to make ptscotch capable of being built with a previously-installed scotch. Only by receiving many such requests are they likely to change. We would already use it from ptscotch-openmpi and ptscotch-mpich.

jedbrown commented on 2013-02-01 17:17

@LWhitson2 OpenFOAM does not have a problem depending on MPI, they just build ptscotch and it installs both libraries. We might be okay with static libraries here. If you want to try adding provides=(scotch) and check that (a) you don't pick up a transitive dependency on MPI and (b) the binary interface is compatible with stand-alone scotch, then I'll add it to this PKGBUILD. (I've been burned in similar ways by this package in the past and don't have time to test thoroughly.)

LWhitson2 commented on 2013-02-01 00:57

If you build scotch/ptscotch with OpenFOAM (currently version 5.11.1), it has two separate header files, scotch and ptscotch.

jedbrown commented on 2013-01-31 23:31

@LWhitson2 How does OpenFOAM do it in other environments? I'd be happy to accept patches, but I'm not interested in spending time on custom mediation of upstream's poorly-factored dependencies.

LWhitson2 commented on 2013-01-31 23:23

We have an interesting problem in that OpenFOAM requires both scotch and ptscotch yet there is no way to install both in this release. Thoughts.....

LWhitson2 commented on 2013-01-29 12:19

Sorry about that. I will take care of the package tonight.

CAVT commented on 2013-01-28 15:14

Please, the package needs updating, otherwise there are cnflicts with newer ptscotch and therefore other softwares depending on them, like OpenFoam.

jedbrown commented on 2013-01-17 14:42

@CAVT The packages are not equivalent and making them so would, at a minimum, require compiling different parts of ptscotch with different compilers (part with mpicc and part with gcc), which is something the build system is not set up to do. You're welcome to ask upstream to factor their packages so that they don't overlap.

CAVT commented on 2013-01-17 14:11

I'm not able to update ptscotch because Pacman says some files already exist in my filesystem, and doing "pacman -Qo" to those files shows they are owned by the scotch package. I suppose ptscotch and scotch are in the same tarball, so I would like to know if it's safe to modify the pkgbuild writing "provides: scotch".

jedbrown commented on 2012-08-29 12:44

@myles That would create a quasi-dependency on parmetis which I'm not thrilled about adding.

myles commented on 2012-08-29 10:40

Thanks for maintaining this package. I think according to the Standards ( headers should go in /usr/include instead of /usr/include/scotch, the file parmetis.h would conflict with that provided by the parmetis package but at the top it says it says "Preferably use the original ParMeTiS include file...".

myles commented on 2012-08-29 10:30

Thanks for maintaining this package. I think according to the Standards ( headers should go in /usr/include instead of /usr/include/scotch, the file parmetis.h would conflict with that provided by the parmetis package but at the top it says it says "Preferably use the original ParMeTiS include file...".

LWhitson2 commented on 2012-07-11 12:54

rememberthemer, thanks for the updated package build. Sorry about the delay in updating this. I must have missed the comment.

If anyone else sees something that needs to be updated, please let me know. As I said below, I am still learning here.

Anonymous comment on 2012-05-17 02:42

At present the way is created there are different compile flags for shared and static libs.
Specifically "-DIDXSIZE64" is ommitted for shared libraries. i.e. The shred and static libs are inconsistent.

Also, Manpages are installed to /usr/man when it should /usr/share/man (ARCH policy)

I have uploaded a fixed PKGBUILD to

LWhitson2 commented on 2012-05-15 19:59

Updated. Thanks for the heads up.

kragacles commented on 2012-05-14 18:36

Could you make one small fix to the PKGBUILD file?

Line 23 ends up creating instead of a file, and as a result the shared scotch libraries never get built. Like so:

- sed "s/-lz -lm -lrt/-lz -lm -lrt -lpthread/" >
+ sed "s/-lz -lm -lrt/-lz -lm -lrt -lpthread/" >


Anonymous comment on 2012-03-16 22:42

thank you alfplayer. Without your comment I wouldn't have been able to build the package.

BELiAL commented on 2012-02-06 09:14

You're welcome!

LWhitson2 commented on 2012-02-05 15:21

I have created an updated PKGBUILD but I can't upload it. If BELiAL is ok with it, I would be happy to take the package over.

alfplayer commented on 2012-01-28 02:08

It doesn't compile until after I add -lpthread to LDFLAGS. I did it like this after cd in build function:
sed -i 's/-lz -lm -lrt/-lz -lm -lrt -lpthread/'

LWhitson2 commented on 2011-12-14 02:04

There is a new version of the Scotch library, 5.1.12b

jedbrown commented on 2011-09-11 21:24

@kkb110 I see you have deleted your comment so maybe you figured it out. This package cannot "provide ptscotch" because the MPI standard does not define an ABI, therefore the binaries for an Open MPI and MPICH2 build of an identical package offering identical functionality are not interchangeable. For example, the size of MPI_Comm is different between Open MPI and MPICH2.

kkimdev commented on 2011-09-11 18:15

I think it's better to have this line.

jedbrown commented on 2011-08-21 02:37

Sorry, this doesn't work because the versions of MPI are not ABI-compatible and only one version of MPI can be used by a particular executable. Therefore ptscotch-openmpi and ptscotch-mpich2 shared libraries are not interchangeable.

kkimdev commented on 2011-08-18 21:55


for both mpich2 and openmpi version

jedbrown commented on 2011-06-17 17:06

updated, thanks

kragacles commented on 2011-06-17 17:05

Hi again, looks like our openmpi fakeroot bug has reared it's ugly head here as well. Coredumps on compile.

Quick patched up PKGBUILD here:

kragacles commented on 2011-06-17 16:58

Hi again, looks like our openmpi fakeroot bug has reared it's ugly head here as well. Coredumps on compile.

Quick patched up PKGBUILD here: