Двоичные файлы из файла fortran

У меня есть двоичный файл, который работает под моей оболочкой по умолчанию.

Бинарный режим отлично работает o.k. с:

./binary input.dat

Однако, если я помещаю это в файл make:

 SHELL=/bin/bash

 runos:
      ./binary input.dat

Код падает и оставляет меня совершенно беспомощным. Вот что я тестировал до сих пор, все внутри файла Make и в оболочке:

  1. ulimit -a: identical.
  2. Set the shell to bash as seen above.
  3. diff of the environment variables in SHELL and Make with:

    env | sort > vars.1

    inside make

    env | sort > vars.2

    Then run the binary with the extra variables in Make with the following command:

    env SHLVL=2 MAKELEVEL=1 MAKEFLAGS= ./binary input.dat

  4. strace in the shell and inside make:

    strace -o debug binary input.dat

Код продолжает сбой в Make и работает в оболочке. Я уже думаю сбрасывать Make для своих тестовых случаев и просто писать сценарии оболочки. Но мне любопытно узнать, в чем разница.

Код Fortran (сочетание F77, F90 и F95) был скомпилирован с gfortran-4.4 и следующими параметрами:

FFLAGS= -g -fbacktrace

Итак, конкретный вопрос заключается в том, что я могу сделать, чтобы сделать этот бинарный запуск под Debian !?

Обновить:

Я просто тестировал снова на машине CentOS (v5.8), код внутри Makefile не сбой (GNU Make версии 3.81). Я также тестировал на своем Debian Wheezy и openSUSE 11.4, как с GNU Make версии 3.82 - он сработает! Я тестировал на Debian Squeeze с GNU Make версии 3.81, и он сбой. Итак, я думаю, что это не зависит от версии GNU Make.

ошибка при сбое:

 enter timeloop
 ------------------------------------------------------------------------
 timestep:     1  time: 2.500E-02 days         delt: 2.500E-02 days        
 -------------------------------------------
    terminated in routine react_snia      
    maximum number of iterations exceeded   
    bye now ...                             
 -------------------------------------------
failure in timeloop
no further time step reduction possible
try reducing min. time step, bye now ...

пытаясь обойти «GNU Make», используя «waf»

Прошло некоторое время с тех пор, как я хотел протестировать waf , вот еще одно интересное замечание: Я написал wscript , который содержит функцию:

import os

def run(ctx):
    os.system('./binary input.dat')

И работает waf run !

Если я изменил метод run , чтобы:

import subprocess as sp
def run(ctx):
    sp.call('./binary input.dat', shell=True)

Бинарный также работает , как и ожидалось.

Итак, теперь я думаю, что GNU Make создает новую под-оболочку таким образом, что причиной может быть двоичная ошибка (хотя в RHEL 5.8 Make сделал работу).

0
добавлено отредактировано
Просмотры: 1
@eriktous, у меня есть сообщения об ошибках из кода, но я не думаю, что они релевантны. Код падает при превышении количества итераций в решателе. Этот номер определяется внутри файла input.dat
добавлено автор Oz123, источник
@eriktous, да, вы правы. У меня есть еще кое-какие идеи ... см. Выше.
добавлено автор Oz123, источник
@george, спасибо, но Fortran действительно примитивен, он даже не имеет getenv (), getarg() в этом коде ... И я уверен, что есть некоторые проблемы с кодом, но прямо сейчас я нужны некоторые утилиты тестирования, которые работают со старым кодом (я реорганизую его, переписывая его на C).
добавлено автор Oz123, источник
@george, да, я сделал. Вы также видите, что я определил shell как/bin/bash, потому что я подозревал ошибку с тире или так. Это также происходит с make-v.3.81 из источников ванили в RHEL5.8 и CentOS 5.8. Патч-версия CentOS \ RHEL не содержит эту ошибку ...
добавлено автор Oz123, источник
Я думаю, ты лаешься по неправильному дереву. Начните искать ошибку в своем коде вместо того, чтобы обвинять make. Код будет заботиться только о его оболочке/среде, если он использует библиотеки DLL или явно меняет переменные среды через getenv (), getarg() и т. Д. Вы читаете из stdin? Если ни одно из перечисленных выше не начнет искать доступ к массиву за пределами границ или что-то подобное, что приводит к изменению поведения в зависимости от того, как память распределяется во время выполнения.
добавлено автор agentp, источник
это нестандартные, но распространенные расширения. В любом случае вы пробовали вызывать свой двоичный файл из сценария оболочки и разрешить вызов сценария? Одна интересная вещь, которую я обнаружил в беспорядке: make использует оболочку, указанную SHELL = в make-файле, но передает переменную SHELL из вызывающей оболочки в процесс. Wierd, но я не могу понять, почему это может вызвать ошибку.
добавлено автор agentp, источник
Нет сообщения об ошибке при сбое кода?
добавлено автор eriktous, источник
Если я правильно понимаю это, он не «рушится» в традиционном смысле этого слова, но программа прекращает изящество, признавая отсутствие конвергенции. Это правильно? Поэтому реальный вопрос заключается в том, почему существует конвергенция при запуске из оболочки, а не при запуске make.
добавлено автор eriktous, источник

1 ответы

решение: скомпилировать make из источников ...

Читайте, чтобы узнать больше.

Хорошо, поэтому, после довольно отчаянного, я сделал то, что просто должен был сделать, прежде чем обвинять make для всех моих проблем.
Я думал, что проблема связана с Debian. Но я предполагаю, что версия в CentOS-5.8 является исправленной версией, хотя она говорит, что это v.3.81.
Итак, для тех, кто задавался вопросом, мое решение было:

wget http://ftp.gnu.org/gnu/make/make-3.82.tar.gz
tar xvzf make-3.82.tar.gz
cd make-3.82
./configure
./build.sh
 # copy make to the directory with the binary and input and run the local make version
./make
# everything works as expected !!!

Я думал, давайте сузить его -

wget http://ftp.gnu.org/gnu/make/make-3.80.tar.gz
tar xvzf make-3.80.tar.gz
cd make-3.80
./configure
./build.sh
 # copy make to the directory with the binary and input and run the local make version
./make
# everything works as expected !!!

Это версия 3.81?

wget http://ftp.gnu.org/gnu/make/make-3.81.tar.gz
tar xvzf make-3.81.tar.gz
cd make-3.81
./configure
./build.sh
 # copy make to the directory with the binary and input and run the local make version
./make
# FAIL! Like with the make version in Debian.

Следовательно, я думаю, что я столкнулся с какой-то очень странной ошибкой в ​​GNU Make v.3.81.

0
добавлено