make install: GMP, MPFR, MPC, ISL, binutils, GCC, MPICH, HDF5, libpng, PETSc

Пост про установку связки компиляторов и библиотек GCC + MPICH + HDF5 + PetSC на чистой системе.

Операционная система: Debian 8.2 в стандартной поставке. В систему включён gcc 4.9 (прекомпилированные бинарники).

Конечная цель: скомпилировать и запустить нашу замечательную софтину, StagYY (кому интересно, одна из базовых статей).

Мотивация: так как я пользуюсь достаточно специфической связкой компиляторов и утилит/библиотек, сильно проще искать проблемы совместимости и компиляции (и их решать!), когда они установлены с чётко известными ключами в чётко известном месте, а все зависимости прописаны ручками и/или одобрены глазками.

Постановка задачи: научиться ставить на максимально голой системе из исходников весь необходимый набор софта. Сборка ведётся в домашней директории пользователя. Это позволяет минимально загадить систему при пересборках и экспериментах.

Дополнительные условия: я пользуюсь последними версиями библиотек, которые зачастую новее тех, которые присутствуют в репозиториях debian.

Цель: получить связку действий, которая гарантирует приход к успеху (компиляция софта по работе) на системе с минимальным содержанием софта. Читать: мазохизм.

 Кратко о том, почему я отказался от системного gcc.

Перед установкой компилятора GCC необходимо установить и собрать несколько библиотек математики. Важно: ставить строго в таком порядке.

1. GMP 6.1.0. Скачиваем архив, распаковываем, переходим в папку, исполняем команды консоли (понадобилось доустановить архиватор lz):
   \$ sudo apt-get install lzip
   \$ tar --lzip -xvf gmp-6.1.0.tar.lz ; cd gmp-6.1.0
   \$ ./configure --prefix=/home/user/bin/gmp --disable-shared --enable-cxx
   \$ make
   \$ make check
   \$ make install
   Очаровательный дисклеймер при установке: "GMP has been carefully tested by its authors, but compilers are all too often released with serious bugs.  GMP tends to explore interesting corners in compilers and has hit bugs on quite a few occasions.
2. MPFR 3.1.3. Аналогично:
   \$ tar -xvf mpfr-3.1.3.tar.xz ; cd mpfr-3.1.3
   \$ ./configure --prefix=/home/user/bin/mpfr -with-gmp=/home/user/bin/gmp --disable-shared
   \$ make
   \$ make check
   \$ make install
3. MPC 1.0.3. Аналогично:
   \$ tar -xvf mpc-1.0.3.tar.gz ; cd mpc-1.0.3
   \$ ./configure --prefix=/home/user/bin/mpc -with-gmp=/home/user/bin/gmp -with-mpfr=/home/user/bin/mpfr --disable-shared
   \$ make
   \$ make check
   \$ make install

PS: в начальную постановку задачи установка этих библиотек не входила. Однако gcc мне заявила, что не может их найти в системе. Ок, сказал я, подавись, гадина.

После этого скачиваем и распаковываем gcc 5.3.0. ВНИМАНИЕ! здесь начинается лирика и боль до конца латинской пословицы! Per aspera ... Исполняем в папочке интуитивно-очевидную команду. configure заявляет, что

/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory

Я говорю "иди нафиг, у нас закрома всего полны":

\$ find /usr/ -name crti*
/usr/lib/x86_64-linux-gnu/crti.o
\$ LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:\$LIBRARY_PATH
\$ export LIBRARY_PATH

И configure падает с заявлением, что она не может найти у меня 32-битных библиотек:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
configure: error: I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.

Господину предлагают либо отключить multilib (оставить только 64битный компилятор без возможности генерации 32х битных исполняемых файлов), либо ещё что-то, что ему было влом читать. Потому Господин написал команду с ключом --disable-multilib и перезапустил. После всех этих плясок с бубном эта зараза мне заявила:

configure: error: error verifying int64_t uses long long

Я спросил у google, и ответил форум мне, что надо gcc-c++ сначала поставить. Решается установкой репозиторного 4.9:

\$ sudo apt-get install g++

Ок, после всего этого configure успешно кончил. Я запустил make. Компиляция компилятора прошла относительно быстро, за 2 часа. Я запустил make check - и он благополучно умер, не приходя в сознание. Выяснилось, что gcc каким-то образом смог сам себя, по канону жанра, три раза перекомпилировать, не имея работающего линкера, который я смог бы вызвать! И даже сделать 1 Гб выходных файлов!

Тут я задумался не тем местом, каким обычно, и сделал вдумчивый RTFM, а именно прочитал полное описание настроек configure для gcc. Желающие могут ознакомиться. Считаю нужным отметить, что это именно то, о чём только и может мечтать любой неженатый мужчина в субботу вечером. Я нашёл забавный ключик --enable-multiarch, а вот ересь поганую с --disable-multilib отправил по назначению. 

Ещё в процессе вдумчивого чтения мануалов и форумов мои руки сделали вот так:

\$ sudo apt-get install lib32gcc1
\$ LIBRARY_PATH=/usr/lib32:\$LIBRARY_PATH
\$ export LIBRARY_PATH

Я не знаю, взлетело бы без этого, и у меня нет сил, мотивации и потенциала это проверять. Рекомендую следующему смертнику падавану попробовать, с интересом прочитаю о последствиях.

Как показала практика и эксперименты, рекомендуемый configure ключ --enable-multilib работает только при --enable-multiarch. Попытка его запуска без --enable-multiarch приводит к тому же результату, что и вообще без --enable-multilib.

Просматривая вывод configure дальше, я нашёл строчки:

checking for compatible ISL... no
*** This configuration is not supported in the following subdirectories:
     target-libmpx gnattools gotools target-libada target-libgo target-libffi target-libbacktrace target-zlib target-libjava target-liboffloadmic target-boehm-gc
    (Any other directories should still work fine.)

zlib - библиотека, нужная мне позарез и потому её присутствие в списке меня сильно напрягло. Признаться, я не знал, насколько связаны между собой эти строчки, потому решил поставить и ISL, благо она маленькая. Пролистав тонны исламских библиотек для linux, я нашёл ISL 0.16 - это тоже математическая библиотека:

\$ ./configure --prefix=/home/user/bin/isl --with-gmp-prefix=/home/user/bin/gmp --disable-shared
\$ make
\$ make check
\$ make install

После чего попробовал  сделать configure gcc с ключом --with-isl=/home/user/bin/isl . Как несложно догадаться, легче не стало. Не помогла и установка dev-библиотек в систему. Помогло добавить в список компилируемых языков java. Нет, не надо спрашивать. Я не готов. Просто компилируй java.
Следует, однако, признать, что надежды на java в configure падают примерно в тот момент, когда пользователь пытается запустить утилиту make. Мне оказалось проще поставить в систему zlib и добавить опцию --with-system-zlib.

Однако мы уже продвинулись дальше, до стадии запуска make. Следующее, во что мы упираемся - это:

configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:15654: recipe for target `configure-stage1-target-libgcc' failed

Тут решение оказалось довольно-таки простое. Вдумчивое изучение файла <адрес директории>/libgcc/config.log показывает, что он не видит libisl.so.15. То есть все его заверения про неизвестность суффиксов - это ложь и провокация. Это вылечилось простейшим экспортом в системную переменную путей для линкера:

\$ export LD_LIBRARY_PATH=/home/user/bin/gmp/:/home/user/bin/mpfr/:/home/user/bin/mpc/:/home/user/bin/isl/lib/

Из разряда "пишите в системные переменные правильно" или "да я лох": упёрся в это сообщение:

checking LIBRARY_PATH variable... contains current directory
configure: error:
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.

Проблема оказалась проста:

\$ echo $LIBRARY_PATH
/lib/i386-linux-gnu/:/usr/lib32:/usr/lib/x86_64-linux-gnu/:

Двоеточие на конце строчки и вызывало падение. Фиксится экпортом строки без двоеточия

После перезапуска make она рухнула чуть дальше:

/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory                               

Это вылечилось просто моментально со словами "да пошла ты!":

\$ sudo apt-get install libc6-dev-i386

Ну и ещё приходилось решать проблемы типа:

configure: error: in `/home/user/Downloads/gccbuild/x86_64-unknown-linux-gnu/libgomp':
configure: error: C compiler cannot create executables

Как выяснилось, на середине первой компиляции до неё внезапно дошло, что я указал путь к своему ld, не написав "ld" (собственно бинарника-линкера) в конце строки, а сама подставить она не смогла. Ок, прописали. Потом у меня начал фатально падать штатный линкер при новейшей версии (2.25) в системе от недопрописанных путей на библиотеки. В этот момент я почувствовал себя уставшим (шли вторые сутки установки) и поехал спать.
Зато на обратном пути со мной познакомились сразу две швейцарки. Компилирование компилятора - +100500 к твоей привлекательности!

Наутро я, вспомнив слова Егора Летова "нечего терять", я пошёл и скачал binutils 2.25, чтобы сделать свой собственный ld. Прочитал ./configure --help, написал команду. Она выводит:

checking for version 0.10 of ISL... no
checking for version 0.11 of ISL... no
checking for version 0.12 of ISL... no
configure: error: Unable to find a usable ISL.  See config.log for details.

Помилуй, любезный! У меня ISL 0.16! Ок, терять нечего, я залезаю в ./configure своими грязными щупальцами и переправляю вручную контроль версий:

{ \$as_echo "\$as_me:\${as_lineno-\$LINENO}: checking for version 0.12 of ISL" >&5
\$as_echo_n "checking for version 0.12 of ISL... " >&6; }

Заменяем 0.12 на 0.16, сохраняем, перезапускаем - вуаля!

\$ ./configure --prefix=/home/user/bin/binutils -with-gmp=/home/user/bin/gmp -with-mpfr=/home/user/bin/mpfr --with-mpc=/home/user/bin/mpc --with-isl=/home/user/bin/isl --enable-lto
\$ make
\$ make install

Моё состояние было уже преисполнено мрачной решимости и знания, что у. меня. всё. получится:

После чего прописал ручками пути к линкерам ld и as в списках ключей к configure моего gcc.

Я не знаю, что делает gcc этим, но я нашёл это в логах установки. В интернетиках комменты типа "компилятор тоже человек, ему нужно кофе". Возможно, и пасхалка, кто знает.

checking the coffee machine... empty - operator may not work as expected

Следующая проблема оказалась в том, что несколько библиотек gcc (srcman, c.scrextra, gcc.srcextra) собирались с error (от make), и параллельно писалось, что:

cp: ‘../../gccsource/gcc/gengtype-lex.c’ and ‘../../gccsource/gcc/gengtype-lex.c’ are the same file

Собственно, это сообщение об ошибке и приводило к невозможности выполнения задания на цели (объектные файлы). Я попробовал для начала заткнуть дыру в титанике грубой правкой gcccource/gcc/Makefile.in с посылом  соответствующего вывода в /dev/null:

-cp -p \$^ \$(srcdir) 2>/dev/null || :

Как и следовало ожидать, сообщение об ошибке копирования исчезло, а вот цели достигаться не стали. Пришлось думать.

Поскольку у меня на тот момент в configure был прописан ключ --enable-generated-files-in-srcdir, который пишет скомпилированные файлы в исходную директорию (да, gcc надо собирать НЕ в директории хранения файлов), я решил, что ошибка cp может быть как-то с этим связана. Я убрал ключ (без которого не работало до этого, до добавления ещё примерно 5 ключей) - и она таки доходит до конца, но катастрофически падает на сверке версий.

Да, GCC компилируется в три прохода. Первый раз - системным компилятором. Второй раз - полученным компилятом. Третий раз - полученным на второй раз дистиллятом. Сверяются результаты (hash-суммы бинарников) второго и третьего прогонов. Если разница превышает критическую массу - происходит коллапс и установка падает.

Удаляю всё и перезапускаю по-чистому:

И он это таки делает!
Одна сборка занимает примерно 4 часа, суммарно отладка заняла примерно 60 часов.

Как может заметить читатель, я не использовал минимум трёх утилит, которые мог бы поставить сам - libelf, CLooG и zlib. Но это я оставляю на следующий раз, благо там всё должно быть довольно линейно. 
Желающие могут ещё попробовать использовать недефолтный make. Я так уже делал.

Ad astra! Боль закончена, играет девятая симфония Шостаковича.

Итак, полный вид команды configure, полученный мною за 2.5 дня:

\$ ../gccsource/configure --prefix=/home/user/bin/gcc -with-gmp=/home/user/bin/gmp -with-mpfr=/home/user/bin/mpfr --with-mpc=/home/user/bin/mpc --with-isl=/home/user/bin/isl --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-lto --enable-multiarch --enable-multilib --with-dwarf2 --disable-nls  --with-system-zlib --with-multilib-list=m32,m64,mx32 --enable-shared='libgcc libstdc++ libffi zlib boehm-gc libobjc' --enable-default-pie --enable-threads=posix --enable-tls --enable-targets=all --enable-fdpic --enable-static --with-diagnostics-color=always --with-gnu-ld --with-ld=/home/user/bin/binutils/bin/ld --with-gnu-as --with-as=/home/user/bin/binutils/bin/as > out_config.txt
\$ make
\$ make -k check
\$ make install

Наконец, make проходит, я перехожу к make -k check, который, естественно, падает:

/bin/bash: autogen: command not found

Решение очевидно:

\$ sudo apt-get install autogen

Кстати, просто чудесного из документации по тестам. No comments:

PASS: the test passed as expected
XPASS: the test unexpectedly passed
FAIL: the test unexpectedly failed
XFAIL: the test failed as expected 

ИИИИИ!!!! ДАААААА!!!!!

./test-demangle: 897 tests, 0 failures
./test-demangle: 230 tests, 0 failures
\$ /home/user/bin/gcc/bin/gcc -L/home/user/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib64/  hi.c
\$ ./a.out
Hello, World

PS для тех, кто думает, как и я в начале, что всё будет норм и быстро: описаны далеко не все выполненные процедуры! По факту, проблем было больше! Описаны только основные milestones of pain и досадные тупяшки.

PPS: у меня жертвой GCC пал шоколадный Дед Мороз: его растаяло выносом из вентилятора ноутбука :) Остаток тела доел, растёкшиеся внутренности отдраил - но так и не сфотографировал :( Я специально сходил в супермаркет купить следующего, уже не невольно, но злоумышленного обречённого на казнь... Но нет, он не вытек так красиво... Он вообще не вытек. Хнык.

PPPS про PPS: вывод: не начинайте программировать. Программирование убивает! Мне кажется, это надо писать на дисках с компиляторами как на пачках сигарет.

А мы меж тем продолжаем наш балет. Следующая приставка - компилятор-покрышка для GCC для параллельных вычислений (MPI). Ставим MPICH 3.2: скачали, распаковали, зашли, понеслася.

Поначалу я хотел его ставить без фортрана-77, благо номинально такая опция есть:

--enable-fortran=option - Control the level of Fortran support in the MPICH implementation.
yes|all   - Enable all available Fortran implementations (F77, F90+)
f77       - Enable Fortran 77 support
fc        - Enable Fortran 90 and 2008 support
no|none   - No Fortran support

По факту, при попытке выбора "fc" configure рухнет с тем, что нельзя так просто взять и поставить f90+, не ставя f77. От слова "вообще". Итоговая строка конфигурации:

\$ LDFLAGS="-Wl,-L/home/user/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib64/" FC=/home/user/bin/gcc/bin/gfortran CC=/home/user/bin/gcc/bin/gcc CFLAGS=" -D_LARGEFILE_SOURCE -D_LARGEFILE64_OFFSET_BITS=64 " F77=/home/user/bin/gcc/bin/gfortran  ./configure --prefix=/home/user/bin/mpich --enable-fortran --with-gnu-ld
\$ make
\$ make check
\$ make install

Все тесты зелёненькие, в task manager я радостно вижу 100% загрузку моей четырёхядерной системы. И даже проверить можно:

\$ /home/user/bin/mpich/bin/mpicc -Wl,-L/home/user/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib64/ hi.c
\$ /home/user/bin/mpich/bin/mpirun -n 8 ./a.out
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World

Следующая процедура - HDF5 1.8.16. Это библиотека для выводного общеупотребительного (широко известного в узких кругах, да) формата выходных файлов, которая ставится надстройкой над компилятором. Над MPICH в нашем случае. И нет, я никому не хочу высказывать своего мнения об этой проктологии, когда для записи XML файлов делается свой компилятор.

\$ LDFLAGS="-Wl,-L/home/user/bin/mpich/lib" FC=/home/user/bin/mpich/bin/mpif90 CC=/home/user/bin/mpich/bin/mpicc ./configure --enable-fortran --enable-parallel --prefix=/home/user/bin/hdf5 --disable-shared --with-gnu-ld

Всё хорошо, только на стадии make check падает с невозможностью найти mpi. Ок, прописываем ручками (отступление от автономной сборки в угоду программе:

\$ sudo ln -s /home/user/bin/mpich/bin/mpiexec /usr/bin/mpiexec
\$ sudo ln -s /home/user/bin/mpich/bin/hydra_pmi_proxy /usr/bin/hydra_pmi_proxy

Тесты пройдены, установка легка и непринуждённа.

Теперь есть первая возможность скомпилировать нашу замечательнейшую софтину, StagYY. Начинаю переписывать makefile компиляции - и понимаю, что у меня не стоит libpng, который нужен для автоматического вывода картинок вместо полей значений (читать: не нужен). Тут банально. Скачали, распаковали:

\$ tar -xvf libpng-1.6.21.tar.xz ; cd libpng-1.6.21/
\$ LDFLAGS="-Wl,-L/home/user/bin/mpich/lib" CC=/home/user/bin/mpich/bin/mpicc ./configure --prefix=/home/user/bin/libpng --with-gnu-ld
\$ make
\$ make check
\$ make install

Теперь важный момент. Поскольку мы установили libpng после сборки ld и у нас появилась новая shared библиотека, надо обновить enviroment variable:

\$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/home/user/bin/libpng/lib

И соответствующим образом допилить строку флагов линкера файла, использующего эту библиотеку:

/home/user/bin/mpich/bin/mpicc -c -I/home/user/bin/libpng/include -lpng  -Wl,-L/home/user/bin/mpich/lib/ -Wl,-L/home/user/bin/libpng/lib/ -Wl,-L/home/user/bin/libpng/lib/ -Wl,-lpng wrtpng.c

Итак, у нас всё заработало. Следующий шаг - это установить библиотеку PETSc 3.6.3. Она позволит перейти в численной схеме с multigrid solver на direct solver, что даёт большую устойчивость численного алгоритма.

Загружаем исходник с сайта, распаковываем. Внимание! Распаковывать надо сразу в директорию, куда она будет установлена, и там же собирать (на досуге сравнить с GCC, который запрещено собирать в директории с исходниками и заплакать).

Далее потребуется установить cmake:

\$ sudo apt-get install cmake

После чего запускам конфигурацию PETSc магической фразой (вот это уж точно у каждого своя будет). Эта фраза требует наличия интернета, поскольку petsc будет скачивать кучу модулей. Собственно, PETSc - это даже не совсем библиотека с конкретным алгоритмом расчёта, но собрание библиотек (интерфейс), созданных условно-сторонними разработчиками.
NB: у меня так и не получилось скомпилировать PETSc с --with-shared-libraries=yes. Падает.

\$ PETSC_DIR=/home/user/bin/petsc PETSC_ARCH=x86_64-linux-gcc-hdf5 ./configure --with-hdf5-dir=/home/user/bin/hdf5/ --with-clanguage=c --with-fortran=1 --download-suitesparse=yes --with-shared-libraries=no --with-fortran-datatypes --with-download-f2cblaslapack=yes --with-mpi-dir=/home/user/bin/mpich --download-fblaslapack=1 --with-x=0 --download-mumps --download-scalapack --download-ptscotch --download-parmetis --with-debugging=no --download-blacs --download-pastix=1 --download-superlu_dist --download-metis --with-mpiexec=/home/user/bin/mpich/bin/mpiexec
\$ make PETSC_DIR=/home/user/bin/petsc PETSC_ARCH=x86_64-linux-gcc-hdf5 all
\$ make PETSC_DIR=/home/user/bin/petsc PETSC_ARCH=x86_64-linux-gcc-hdf5 test
\$ make PETSC_DIR=/home/user/bin/petsc PETSC_ARCH=x86_64-linux-gcc-hdf5 streams NPMAX=4

Я это сделал, я внёс изменения в makefile нашей софтины - и ничего не заработало. Причины: главная: с версии 3.5.3, инструкция к которой у меня была, поменялся путь к файлу variables, в котором прописаны необходимые переменные окружения. Да, там просто ад, содом и винегрет из десятков ИХ. Потому годная запись в makefile выглядит примерно так:

PETSC_DIR = /home/user/bin/petsc
PETSC_ARCH = x86_64-linux-gcc-hdf5
include \${PETSC_DIR}/lib/petsc/conf/variables
PETSC_LIB = -L \$(PETSC_DIR)/\$(PETSC_ARCH)/lib
PETSC_INCL = -I \$(PETSC_DIR)/\$(PETSC_ARCH)/include \${PETSC_KSP_LIB}

Здесь очень важно всё правильно прописать, поскольку всё будет компилироваться и валиться на стадии линкования. И обязательно вдумчиво зачитать не только стандартные вещи типа /configure --help и installation guide, но и changes log. 

Честно говоря, у меня ушло весьма продолжительное время на то, чтобы прописать всё правильно и чтобы всё слинковалось. Несколько раз хотелось всё бросить и уйти пить ванильный кофе и плакать в подушку.
Кстати, инфа для гиков: PETSc умеет собираться под iPhone/iPad. Мне кажется, это нужно каждому.

Я тоже не читал changes log перед установкой.

И вот, барабанная дробь, всё слинковано!

Преисполненный радости (ну уж всё работает!), я под "Колоколенку" (feat. Монгол Шуудан) я командую:

\$ mpiexec -n 4 ./stagyympi --options-file ./PETSC_OPTIONS

И она падает с выводом:

HYDU_create_process (utils/launch/launch.c:75): execvp error on file ./stagyympi (permission denied)

Ошибка нестандартная. В интернетиках об этом ничего нет. Потратив полчаса на форумы, под "Сосиски" Ден Назгула уехал на последнем трамвае домой.

Итак, день четвёртый. Я понимаю, что если MPI версия работает, а MPI+PETSc (единственное отличие) - уже нет, то проблема в PETSc. Линкование идёт. Компиляция проходит. Конфиги написаны. Enviroment variables прописаны по самое не балуй. 

Полез прописывать вручную файлы hosts и прочее, что вообще не нужно при выполнении mpiexec.hydra на локальной машине. Попытался посмотреть настройки firewall - ничего не проходит. И даже с правами root (хохмы ради попробовал) - permission denied.

Единственное, что возможно - это в исполняемом файле что-то переклинивает в сама PETSc. Вывод: надо очистить все ключи сборки нашей софтины в её makefile. Итак, Sabaton "The final solution". искореняем ересь святым огнём инквизиции. Я вычистил тупо все переменные, по принципу "вот так ещё линкуется, а вот так ещё нет". По факту - просто вычистил избыточные указания на include/lib файлы библиотек. 

Собираю. Больше чистить нечего. Запускаем:

\$ mpiexec -n 4 ./stagyympi --options-file ./PETSC_OPTIONS

Запустилась!!!

Только как только расчёт доходит до вызова PETSc, PETSc орёт благим матом и падает. Выяснилось, что (не знаю, откуда такое взялось вообще), mpiexec не понимает опцию --options-file ./PETSC_OPTIONS. Запускать надо, прописав ключи ручками в строку запуска:

\$ mpiexec -n 4 /home/user/bin/SV20151215direct/stagyympi -stokes_pc_type lu -stokes_pc_factor_mat_solver_package mumps -mat_mumps_icntl_23 200 -heat_pc_type lu -heat_pc_factor_mat_solver_package mumps -stokes_ksp_type fgmres -heat_ksp_type fgmres

И всё заработало.

UPD:

Немного отладочной информации. Чтобы проверить список shared-библиотек, от которых зависит приложение, можно сделать вот так:

\$ ldd ./stagyympi
linux-vdso.so.1 (0x00007fff92d44000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc005ab1000)
libmpi.so.12 => /home/fomin/bin/mpich/lib/libmpi.so.12 (0x00007fc005623000)
libpng16.so.16 => /home/fomin/bin/libpng/lib/libpng16.so.16 (0x00007fc0053f2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc0051d5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc004fcd000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fc004caf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc0049ae000)
libmpifort.so.12 => /home/fomin/bin/mpich/lib/libmpifort.so.12 (0x00007fc004778000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fc00453b000)
libmpicxx.so.12 => /home/fomin/bin/mpich/lib/libmpicxx.so.12 (0x00007fc00431a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc00400f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc003e0b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc003bf5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00384c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc005ccc000)

В том случае, если вы хотите добавить какую-нибудь библиотеку, надо отредактировать файлик, в котором лежат все зависимости, дописав в конце нужные пути (debian, зависит от операционки!):

\$ sudo nano /etc/ld.so.conf

После чего обновить список зависимостей:

\$ sudo ldconfig -v

Мне это помогло избавиться от утомляющей необходимости добавлять в пути libpng.

Итоги: потрачено: 90 часов, включая сон и прогулки. Скилы +30, ощущение возможности решать любые проблемы +50, удовлетворённость: играет ДДТ "Победа".

Надеюсь, что описание поможет кому-нибудь. Хотя бы мне. В следующий раз.