Package Details: scotch 6.0.4-3

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: ioquatix
Last Packager: ioquatix
Votes: 29
Popularity: 0.435319
First Submitted: 2006-11-07 17:51
Last Updated: 2017-01-25 00:12

Dependencies (3)

Required by (10)

Sources (1)

Latest Comments

AsmundEr commented on 2017-04-04 06:53

Further investigation revealed this was just me being stupid and running out of space in /tmp, so the check() function couldn't create /tmp/rand.dat. Sorry about the noise, everything seems to work fine now.

ioquatix commented on 2017-04-03 11:30

Can you try cloning the repo for this package and building somewhere other than tmp?

AsmundEr commented on 2017-04-03 11:29

To be specific, I am installing using yaourt, and the check() function failed saying

./test_common_random /tmp/rand.dat 0
ERROR: main: cannot replay random sequence

Is this just a file it can't find during testing?

ioquatix commented on 2017-04-03 11:28

What does the check function do? I know the maintainer of scotch was receptive to improvements in the build system. I already pointed him at all the hacks in the PKGBUILD...

AsmundEr commented on 2017-04-03 11:27

I may have just cracked the riddle: when it failed for me, it first failed in the check() function saying "cannot replay random sequence". So I commented that out, and restarted the build, upon which it gave the error message mentioned on 2017-03-29. But now I tried a fresh build where I commented the check() out before the first build, and it now works fine!

ioquatix commented on 2017-04-03 11:13

For me, SCOTCH_archInit is defined in "src/scotch_6.0.4/src/libscotch/library_arch.c".

ioquatix commented on 2017-04-03 11:10

Ah right. I have nothing to do with "scotch_esmumps" nor "OpenFOAM". But, I did help maintain this package because it was a bit broken before, and I used OpenFOAM 3.x for a while.

I just tried building the package again and it is working for me. That's odd. I looked for the specific line you quoted, and I have it, and it works fine.

What version of GCC are you using? Is your system up to date?

AsmundEr commented on 2017-04-03 10:53

@ioquatix When I tried to install OpenFOAM, I had scotch installed from an old package "scotch_esmumps" that provides "scotch", so when OpenFOAM PKGBUILD checks "is scotch provided?" the answer is "yes", but then their PKGBUILD calls "pacman -Q scotch" to get the scotch version, and that command fails and stalls the build.

What details do you need about my system? It is an up-to-date 64bit Arch box with Intel Core i7-3770, 32 GB memory.

ioquatix commented on 2017-03-29 23:03

@AsmundER Thanks for the update. Please report problem to OpenFOAM and let me know what happens. This package is called scotch, so I'm a little bit confused about the problem you are having.

I have not seen that error before. Can you provide some more details about your system?

AsmundEr commented on 2017-03-29 13:20

I also had a "scotch problem" when installing OpenFOAM, which led me here. It's not actually a problem with this package, but with OpenFOAM trying to determine the scotch version by using `pacman -Q scotch`. This obviously fails if the user has installed a package that is not named "scotch" but provides scotch. I will report the bug on the OpenFOAM package.

As for building this package, I have not been able to get it to work, it fails at:

gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME -DSCOTCH_PTHREAD -Drestrict=__restrict -DIDXSIZE64 -I../../include -I../libscotch acpl.c -o acpl -L../../lib -lscotch -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
/tmp/cc0ZwJQa.o: In function `main':
acpl.c:(.text.startup+0x13b): undefined reference to `_SCOTCHfileBlockOpen'
acpl.c:(.text.startup+0x143): undefined reference to `SCOTCH_archInit'
acpl.c:(.text.startup+0x152): undefined reference to `SCOTCH_archLoad'
acpl.c:(.text.startup+0x15a): undefined reference to `SCOTCH_archName'
acpl.c:(.text.startup+0x1f1): undefined reference to `_SCOTCHusagePrint'
acpl.c:(.text.startup+0x268): undefined reference to `SCOTCH_archSave'
acpl.c:(.text.startup+0x279): undefined reference to `_SCOTCHfileBlockClose'
acpl.c:(.text.startup+0x281): undefined reference to `SCOTCH_archExit'
../../lib/ undefined reference to `scotchyylval'
collect2: error: ld returned 1 exit status

ioquatix commented on 2017-01-25 11:08

I've been in touch with the developer of scotch and he is going to attempt to fix some of the current issues and release 6.0.5

In any case, it should be fine for OpenFOAM, I've been using it. Can you explain in more detail the error when building OpenFOAM?

ingleandrobarros commented on 2017-01-25 06:02

scotch don't run correctly for install OpenFOAM. What's the problem?

ioquatix commented on 2017-01-25 00:06

Yes, the undefined reference to scotchyywrap should have been fixed in the latest PKGBUILD in git.

eolianoe commented on 2017-01-24 21:30

I have some errors message linked to "undefined reference to scothyywrap", are they linked to your comments about bison/flex?

ioquatix commented on 2017-01-10 00:57

I tried to build this package today. I found new issues with bison/flex changes.

I contact the maintainer of the source code to find out how to fix upstream.

There are other issues but I can't reproduce the ones by franzf and Aeronaelius.

This package is being maintained but PKGBUILD file is fixing so many issues. I'd rather fix upstream. It's crazy.

Aeronaelius commented on 2017-01-09 03:59

I am facing the same error as franzf:

./test_common_random /tmp/rand.dat 0
ERROR: main: cannot replay random sequence

I gladly accept any help.

franzf commented on 2016-08-11 12:48

It does not seem to build:

./test_common_random /tmp/rand.dat 0
ERROR: main: cannot replay random sequence
make[2]: *** [Makefile:121: check_common_random] Error 1

Appreciate any help with this.

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: