Package Details: scotch 7.0.1-1

Git Clone URL: https://aur.archlinux.org/scotch.git (read-only, click to copy)
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: https://gitlab.inria.fr/scotch/scotch
Licenses: custom:CeCILL-C
Conflicts: ptscotch-openmpi, scotch_esmumps, scotch_esmumps5
Provides: ptscotch, ptscotch-openmpi, scotch_esmumps, scotch_ptesmumps
Submitter: None
Maintainer: ioquatix (MartinDiehl)
Last Packager: MartinDiehl
Votes: 35
Popularity: 0.007045
First Submitted: 2006-11-07 17:51 (UTC)
Last Updated: 2022-02-15 11:53 (UTC)

Latest Comments

carlosal1015 commented on 2022-01-06 20:39 (UTC) (edited on 2022-01-10 17:13 (UTC) by carlosal1015)

Edited 2022-01-10

Thank you is fixed now, as GitHub runner or GitLab runner.

Edited 2022-01-07

Building scotch 7.0.0-2 with GitHub runner: (full log here).

You are right @lahwaacz.

lahwaacz commented on 2022-01-06 20:10 (UTC)

@carlosal1015 As far as I understand, your runner has only 1 vCPU: https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html So you can't use that as an argument that everything should be all right...

gpettinello commented on 2022-01-06 16:27 (UTC)

latest commit freezes during dgord test. Noticed that formerly the mod was:

sed -i "s/-DSCOTCH_PTHREAD/-DSCOTCH_PTHREAD -DSCOTCH_PTHREAD_MPI/" Makefile.inc

and now it is

sed -i "s/-DSCOTCH_PTHREAD/-DSCOTCH_PTHREAD -g/" Makefile.inc

reverting fixes the compiling

MartinDiehl commented on 2021-07-05 08:26 (UTC)

6.1.1 works for me, but export FC=gfortran is needed in check.

vanja_z commented on 2021-05-06 09:01 (UTC) (edited on 2021-05-06 09:03 (UTC) by vanja_z)

I cannot build this package either, was running a previous version fine but 6.1.0-1 fails with:

Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
make[2]: *** [Makefile:582: check_prog_dgpart] Error 159
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:577: check_prog_dgord] Error 159
make[2]: *** [Makefile:588: check_prog_dgscat-dggath] Error 159
make[2]: *** [Makefile:410: check_scotch_dgraph_grow] Error 159
make[2]: *** [Makefile:596: check_prog_dgtst] Error 159
make[2]: *** [Makefile:383: check_scotch_dgraph_band] Error 159
make[2]: *** [Makefile:392: check_scotch_dgraph_coarsen] Error 159
make[2]: *** [Makefile:428: check_scotch_dgraph_redist] Error 159
make[2]: *** [Makefile:419: check_scotch_dgraph_induce] Error 159
make[2]: *** [Makefile:401: check_scotch_dgraph_check] Error 159
make[2]: Leaving directory '/home/vanja/.cache/rua/build/scotch/src/scotch-v6.1.0/src/check'
make[1]: *** [Makefile:83: ptcheck] Error 2
make[1]: Leaving directory '/home/vanja/.cache/rua/build/scotch/src/scotch-v6.1.0/src/check'
make: *** [Makefile:116: ptcheck] Error 2
==> ERROR: A failure occurred in check().
    Aborting...

sylphio commented on 2021-05-01 13:58 (UTC)

I get the following build error on the latest version:

../../bin/gdump: symbol lookup error: ../../bin/gdump: undefined symbol: SCOTCH_graphDump
make[2]: *** [Makefile:303: test_scotch_graph_dump2.c] Error 127

Can anyone reprodudce this? Should I report it upstream?

ioquatix commented on 2021-04-28 05:59 (UTC)

Hi, sorry about the long delay. I have a working relationship with the author of this code. I am happy to add someone as a co-maintainer, just let me know.

MartinDiehl commented on 2021-04-14 04:21 (UTC)

scotch 6.1.0 is released and it seems to work without any problems. At leas building the package requires just to change version and checksum.

a.kudelin commented on 2020-03-22 14:30 (UTC)

Please, add the following line to PKGBUILD:
options=(!emptydirs)

acxz commented on 2020-01-18 07:58 (UTC)

@sigvald I created a scotch-git(https://aur.archlinux.org/packages/scotch-git) package that has your fix. Hopefully upstream resolves it soon and @ioquatix can add the fix in the PKGBUILD. But until @ioquatix adds the build fix, feel free to use scotch-git.

lahwaacz commented on 2020-01-17 19:48 (UTC)

It seems like they're doing it on purpose: https://gitlab.inria.fr/scotch/scotch/commit/633f3392d14f5a81ff0f40077f9601bc4d56e0a3

ioquatix commented on 2020-01-17 19:32 (UTC)

@lahwaacz can you file an issue upstream? Or should we modify PKGBUILD?

lahwaacz commented on 2020-01-17 12:11 (UTC)

The package installs an empty directory /usr/include_stub/ which should be removed.

acxz commented on 2020-01-12 19:00 (UTC)

@ioquatix can you pretty please add @sigvald's suggestion in the PKGBUILD? At the very least until upstream fixes the issue. It would mean a lot.

sigvald commented on 2020-01-12 17:48 (UTC)

@acxz and @adsun: This is an old, recurring error. Please see my comment from february 2018: https://aur.archlinux.org/packages/scotch/?O=10&PP=10 . I really don't understand why this is not fixed yet.

adsun commented on 2020-01-12 15:07 (UTC)

@acxz For me the check() function succeeds in a clean chroot. I noticed you are using an AUR helper, so that could be the problem.

acxz commented on 2020-01-12 13:32 (UTC)

Sadly still getting errors: https://gist.github.com/acxz/324e03c50a8d91cc727bbcb81d090341

ioquatix commented on 2020-01-12 00:19 (UTC)

I've bumped to v6.0.9 and it seems to be okay. Let me know how you all get on!

adsun commented on 2019-11-26 16:53 (UTC)

@ioquatix Version 6.0.9 is out. Does that fix the problem with the tests?

ioquatix commented on 2019-10-26 05:20 (UTC)

I have a worktree with 6.0.8 but it doesn't build. I've passed all details upstream. It's a bug with the tests.

acxz commented on 2019-10-26 01:38 (UTC)

Is there an ETA on when this package will be updated? If not updated, then at least fixed so that the dependent packages can also be installed. Thank you

steinbuch commented on 2019-10-22 12:19 (UTC)

Now 6.0.8 is out. But tests fail!

ioquatix commented on 2019-09-10 07:31 (UTC)

The latest update has some issues, I am working with upstream to resolve them before publishing.

MartinDiehl commented on 2019-08-25 18:41 (UTC)

Please find an update to 6.0.7 on https://webshare.mpie.de/index.php?74a503e2b8

It also includes the new project URL and a fix for the error reported by jotapeuy. Not sure if the fix works for MPICH, but I hope that it will get fixed upstream anyway.

ioquatix commented on 2018-09-15 23:40 (UTC)

It's probably better to fix these issues in the package itself. I sent the message upstream.

jotapeuy commented on 2018-09-12 10:23 (UTC)

I've just installed the version 6.0.6-1 and obtained the error "There are not enough slots available in the system to satisfy the 3 slots..." It was solved by editing the PKGBUILD with the solution given by @sigvald commented on 2018-02-19 15:18 (thanks sigvald). Wouldn't be better to add this to the pkgbuild?

ioquatix commented on 2018-07-15 06:38 (UTC)

Okay, the v6.0.6 release is available.

ioquatix commented on 2018-06-25 04:02 (UTC)

Here is the new home for the project. https://gitlab.inria.fr/scotch/scotch

I've contacted the author again, I hope there will be a 6.0.6 release soon. Please be patient.

ioquatix commented on 2018-06-25 04:00 (UTC)

I am working with the author of this package, but I don't believe the next major release has been completed yet.

sigvald commented on 2018-06-20 20:24 (UTC)

@phleva: Indeed, "makepkg -sric --cleanbuild" (not pacman) got rid of some errors for me too.

Why is this package ouf-of-date by the way? Is it being deprecated in favor of scotc-mpich? Or is it a matter of so far unresolved issues?

ioquatix commented on 2018-02-26 01:53 (UTC)

I am communicating with the original developer and I hope there would be a good solution soon.

phleva commented on 2018-02-23 21:21 (UTC)

Just want to thank @AsmundEr and @sigvald and maybe help others along the way. Trying to build on a virtual machine with only one processor I ran into the mpirun limitation forementioned. Adding the --oversubscribe flag in the pkgbuild got rid of the error. Also, managed to clear the other errors by cleaning before and having the package localy. "pacman -sric --cleanbuild"

ioquatix commented on 2018-02-19 22:25 (UTC)

@sigvald I have passed your feedback upstream and will attempt to address your issues when I hear back.

sigvald commented on 2018-02-19 15:18 (UTC)

So I managed to install it and the mpirun problem was indeed a problem on my computer and not on the package per se. I'll give workarounds for both issues:

So for the SSL problem I don't know what's up with the SSL of that site. For those who are ready to take the chances of trusting this site, download the source file (http://gforge.inria.fr/frs/download.php/file/34618/scotch_6.0.4.tar.gz) into your scotch folder and run "makepkg -sri". Since the file is already there, it won't complain that the certificate of the site is not trusted.

Second, the testing of scotch involved running something on 4 processes while my laptop only have 2 cores. This was not a problem with my old installation of OpenMPI (perhaps an OpenMPI 3 thing?). If you can't run "mpirun -n 4 echo hello" then you have this problem too. However, adding "--oversubscribe" allows you to run 4 processes. I made makepkg add this flag to the test by adding a sed-line in the the check() function in the PKGBUILD file as follows:

check() {
  cd "${srcdir}/${pkgname}_${pkgver}/src"

  sed -i 's/mpirun/mpirun --oversubscribe/' check/Makefile

  make check LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:../../lib"
  make ptcheck LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:../../lib"
}

And that made it work. May I suggest adding that sed-line permanently to this PKGBUILD?

sigvald commented on 2018-02-19 12:46 (UTC) (edited on 2018-02-19 12:48 (UTC) by sigvald)

It seems that this error is because the source of the .tar.gz file used to be on an http:// adress but now it is forwarded to an https:// adress (but otherwise the same adress) and my system cannot verify the validity of the certificate. Of course, neither can I, but if you decide to "trust" the source anyway, you can download the .tar.gz-file to your clone of the scotch folder and run makepkg -sri again. Since the source file is already there it won't use curl to try to download it. That gets us one step further, but now I get this one:

mpirun -n 4 ./test_scotch_dgraph_check data/bump.grf
--------------------------------------------------------------------------
There are not enough slots available in the system to satisfy the 4 slots
that were requested by the application:
  ./test_scotch_dgraph_check

Either request fewer slots for your application, or make more slots available
for use.
--------------------------------------------------------------------------
make[2]: *** [Makefile:258: check_scotch_dgraph_check] Error 1
make[2]: Leaving directory '/home/sigvald/Downloads/scotch/src/scotch_6.0.4/src/check'
make[1]: *** [Makefile:68: ptcheck] Error 2
make[1]: Leaving directory '/home/sigvald/Downloads/scotch/src/scotch_6.0.4/src/check'
make: *** [Makefile:106: ptcheck] Error 2
==> ERROR: A failure occurred in check().
    Aborting...

I find this a bit strange since I don't normally have any problem running mpirun with 4 processes.

ioquatix commented on 2018-02-19 12:38 (UTC)

I get the same problem now. Is there something wrong with the SSL on that website?

sigvald commented on 2018-02-19 12:32 (UTC) (edited on 2018-02-19 12:46 (UTC) by sigvald)

I get the following:

==> Making package: scotch 6.0.4-3 (Mon Feb 19 13:31:18 CET 2018)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading scotch_6.0.4.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   360  100   360    0     0   1592      0 --:--:-- --:--:-- --:--:--  1592
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: <https://curl.haxx.se/docs/sslcerts.html>

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
==> ERROR: Failure while downloading <http://gforge.inria.fr/frs/download.php/file/34618/scotch_6.0.4.tar.gz>
    Aborting...

zoidberg commented on 2018-01-07 08:03 (UTC) (edited on 2018-01-07 08:05 (UTC) by zoidberg)

I am unable to build this package on an up-to-date Arch system. I have pasted the last few lines of the build output below.

make[2]: Entering directory '/home/kishore/.cache/pacaur/scotch/src/scotch_6.0.4/src/check'
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_common_random.c -o test_common_random -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_common_thread.c -o test_common_thread -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_strat_seq.c -o test_strat_seq -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_coarsen.c -o test_scotch_graph_coarsen -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_coarsen_build.c -o test_scotch_graph_coarsen_build -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_color.c -o test_scotch_graph_color -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_map.c -o test_scotch_graph_map -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_map_copy.c -o test_scotch_graph_map_copy -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_order.c -o test_scotch_graph_order -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME  -Drestrict=__restrict -DIDXSIZE64 -I../../include -L../../lib test_scotch_graph_part_ovl.c -o test_scotch_graph_part_ovl -lscotch -lscotcherrexit -lz -lbz2 -lm -lrt -pthread
../../bin/gord data/bump.grf /dev/null -vt
../../bin/gord: symbol lookup error: ../../bin/gord: undefined symbol: fileBlockInit
make[2]: *** [Makefile:152: check_prog_gord] Error 127
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/kishore/.cache/pacaur/scotch/src/scotch_6.0.4/src/check'
make[1]: *** [Makefile:65: check] Error 2
make[1]: Leaving directory '/home/kishore/.cache/pacaur/scotch/src/scotch_6.0.4/src/check'
make: *** [Makefile:103: check] Error 2
==> ERROR: A failure occurred in check().
    Aborting...

AsmundEr commented on 2017-04-04 06:53 (UTC)

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 (UTC)

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

AsmundEr commented on 2017-04-03 11:29 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

@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 (UTC)

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/libscotch.so: undefined reference to `scotchyylval' collect2: error: ld returned 1 exit status

ioquatix commented on 2017-01-25 11:08 (UTC)

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 (UTC)

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

ioquatix commented on 2017-01-25 00:06 (UTC)

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

eolianoe commented on 2017-01-24 21:30 (UTC)

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 (UTC)

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 (UTC) (edited on 2017-01-09 16:38 (UTC) by Aeronaelius)

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 (UTC)

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.

eleftg commented on 2015-08-25 19:42 (UTC)

@getzze 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 (UTC)

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 (UTC)

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

eleftg commented on 2015-03-10 08:23 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

oops: http://pastebin.com/T7KsDrvn

eleftg commented on 2015-02-20 17:25 (UTC)

@keepitsimpleengr 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 (UTC)

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 (UTC)

scotch hanging during compilation. termout @ http://pastebin.com/2PqGp31M -- 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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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

eolianoe commented on 2015-02-16 11:49 (UTC)

@eleftg: * yes, you should keep ptscotch-openmpi until the depends arrays of the other package are updateed, * according to http://mumps.enseeiht.fr/index.php?page=faq#20, 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 (UTC)

@ 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 https://lists.archlinux.org/pipermail/aur-general/2015-February/030301.html -- 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 (UTC)

I've orphaned https://aur.archlinux.org/packages/scotch_esmumps in case anyone here is interested in maintaining it

eolianoe commented on 2015-02-15 19:16 (UTC)

@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'): http://pastebin.com/hBPqEVJ8

eleftg commented on 2015-02-14 08:05 (UTC)

Well... yes, sure. Why not?

mickele commented on 2015-01-29 08:17 (UTC)

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

eleftg commented on 2015-01-28 22:51 (UTC)

this package conflicts with gpart (https://www.archlinux.org/packages/extra/x86_64/gpart/) The reason is an executable with identical name: /usr/bin/gpart

mickele commented on 2014-12-14 10:46 (UTC)

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

mickele commented on 2014-12-12 22:23 (UTC)

@saxonbeta I changed the PKGBUILD according to you suggestion. PS: added line is options=('!makeflags') ;-)

saxonbeta commented on 2014-12-10 20:34 (UTC)

Hi, when i try to compile the package I get the following error: make[2]: *** There is no rule to build the target 'libptesmumps.so' In my makepkg.conf I have the option MAKEFLAGS="-j4". After I have removed it, the package compiles fine. I think the line: options=('!nomakeflags') should be added to the PKGBUILD. Cheers!

gucong commented on 2014-02-18 12:45 (UTC)

openmpi in archlinux is not built with thread support (See https://bugs.archlinux.org/task/31715), 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" Makefile.inc

jedbrown commented on 2014-01-26 17:54 (UTC)

@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 (UTC)

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 (UTC)

Solved adding export MAKEFLAGS="-j1" According to this https://github.com/mylese/fenics-arch/blob/master/petsc.pkgbuild Please update PKGBUILD.

Raptorista commented on 2013-10-07 16:02 (UTC)

I'm trying to compile but I get this error: «no rule specified for target «libptesmumps.so», 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 (UTC)

Gug, I have made those two improvements, thanks.

gdolle commented on 2013-08-05 10:19 (UTC)

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 (UTC)

Hi, the libraries "libesmumps.so" and "libptesmumps.so" 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.

commented on 2013-05-19 14:51 (UTC)

Sorry for double post but fixed by symlinking # ln -s /usr/lib/openmpi/libmpi.so.1 /usr/lib

commented on 2013-05-19 14:46 (UTC)

I can't build this : ./ptdummysizes library_pt.h ptscotch.h ./ptdummysizes: error while loading shared libraries: libmpi.so.1: 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 (UTC)

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 (UTC)

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 (UTC)

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

coincoin commented on 2013-03-09 20:57 (UTC)

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 (UTC)

@dibanez Okay, updated this and ptscotch-openmpi.

commented on 2013-03-02 23:20 (UTC)

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" Makefile.inc

myles commented on 2013-02-15 15:02 (UTC)

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

LWhitson2 commented on 2013-02-02 02:40 (UTC)

@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 (UTC)

@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 (UTC)

... 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 (UTC)

@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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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

CAVT commented on 2013-01-28 15:14 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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

myles commented on 2012-08-29 10:40 (UTC)

Thanks for maintaining this package. I think according to the Standards (https://wiki.archlinux.org/index.php/Arch_Packaging_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 (UTC)

Thanks for maintaining this package. I think according to the Standards (https://wiki.archlinux.org/index.php/Arch_Packaging_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 (UTC)

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.

commented on 2012-05-17 02:42 (UTC)

At present the way Makefile.inc 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 http://pastebin.com/BFH7Cgzb

LWhitson2 commented on 2012-05-15 19:59 (UTC)

Updated. Thanks for the heads up.

kragacles commented on 2012-05-14 18:36 (UTC)

Could you make one small fix to the PKGBUILD file? Line 23 ends up creating Makefile.in instead of a Makefile.inc file, and as a result the shared scotch libraries never get built. Like so: - sed "s/-lz -lm -lrt/-lz -lm -lrt -lpthread/" Make.inc/Makefile.inc.i686_pc_linux2.shlib > Makefile.in + sed "s/-lz -lm -lrt/-lz -lm -lrt -lpthread/" Make.inc/Makefile.inc.i686_pc_linux2.shlib > Makefile.inc Thanks!

commented on 2012-03-16 22:42 (UTC)

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

BELiAL commented on 2012-02-06 09:14 (UTC)

You're welcome!

LWhitson2 commented on 2012-02-05 15:21 (UTC)

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 (UTC)

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/' Make.inc/Makefile.inc.i686_pc_linux2 Make.inc/Makefile.inc.i686_pc_linux2.shlib

LWhitson2 commented on 2011-12-14 02:04 (UTC)

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

jedbrown commented on 2011-09-11 21:24 (UTC)

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

jedbrown commented on 2011-08-21 02:37 (UTC)

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 (UTC)

suggestion: provides=('ptscotch') for both mpich2 and openmpi version

jedbrown commented on 2011-06-17 17:06 (UTC)

updated, thanks

kragacles commented on 2011-06-17 17:05 (UTC)

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: http://pastie.org/2083504