Дело для меня очень важное Раньше я в Паскале програмировал, но только сам для себя. На Fortran написал только одну прогу, но, на мой взгляд довольно сложную. Мне передали код программы и подпрограмм, раньше у них все это работало, а у меня компилируется с ошибками. Опыта не хватает, уже больше недели промучался, решил обратиться к помощи более опытных людей.

Итак, имею такие файлы: 

output.for - сама программа, дальше подрограммы

pinread.for
pureread.for
ABEOS10.for
Initial.for
multifac.for
SETEOS10.for

Логически pinread.for должна выполняться первой, поэтому с нее и начал. Она берет данные из внешнего файла.

Так вот при компиляции возникают такие ошибки:

--------------------Configuration: pinread - Win32 Debug--------------------
Linking...
pinread.obj : error LNK2001: unresolved external symbol _TRIMLEN@8
pinread.obj : error LNK2001: unresolved external symbol _STRINT@20
pinread.obj : error LNK2001: unresolved external symbol _LEFT@8
pinread.obj : error LNK2001: unresolved external symbol _CASEFOLD@8
pinread.obj : error LNK2001: unresolved external symbol _LENCHAR@8
pinread.obj : error LNK2001: unresolved external symbol _SHIFT@12
pinread.obj : error LNK2001: unresolved external symbol _PUTINKOM@8
pinread.obj : error LNK2001: unresolved external symbol _KOM2IV@20
pinread.obj : error LNK2001: unresolved external symbol _KOM2R8V@20
pinread.obj : error LNK2001: unresolved external symbol _STRREAL8@20
dfor.lib(DFORMAIN.OBJ) : error LNK2001: unresolved external symbol _MAIN__
Debug/pinread.exe : fatal error LNK1120: 11 unresolved externals
Error executing link.exe.

pinread.exe - 12 error(s), 0 warning(s)

В чем проблема, куда копать? Может кто-нибудь подсказать?

P.S. Исходный код pinread прикрепил файлом


Присоединённый файл ( Кол-во скачиваний: 6 )
 pinread.for 5,08 Kb

Компилируется она без ошибок. Это ошибки линковщика. Так и должно быть, ведь ты не указал ему остальные объектники. (Они соответственно из других for-ов получаются). 

Ну да, Точно, компилируется, но экзешник не создается и программа не запускается. А как указать ему объектники?

Кстати, для каждой подпрограммы и программы нужно создавать отдельный проект в Fortran? Или все в один проект и вместе компилировать? Если в один, то в какой структуре и как это правильней сделать?

Файл с основной программой и файлы с подпрограммами включи в один проект. Если подразумевается фортран-проект в рамках какой-либо IDE, то "нажатие кнопки" компоновки (Build) проекта приведет к компиляции всех (нескомпилированных) исходников  +  компоновка(линковка) полученных при компиляции объектников. Можно отдельные файлы проекта компилить по отдельности, а потом компоновать.
( Можно конечно компилить подпрограммы в разных проектах а затем объектные файлы включать в проект с главной программой - но это делается, как правило, если подпрограммы большие и/или над ними работают разные программисты и/или они часто используются в разных проектах. Также можно часто используемые подпрограммы оформить в виде статических или динамических библиотек) 


Это сообщение отредактировал(а) FCM - 16.5.2009, 13:21

Спасибо за объяснение. Собрал все в один проект, теперь ошибки линковщика пропали.
Сейчас обнаружил ошибки программного кода в файлах output.for и pureread.for.
В output.for 4 ошибки:
output.for(118) : Error: Syntax error, found '.' when expecting one of: <LABEL> <END-OF- 
output.for(135) : Error: Syntax error, found '.' when expecting one of: <LABEL> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE CHARACTER ...
output.for(65) : Warning: A jump into a block from outside the block may have occurred.   [9999]
output.for(107) : Warning: A jump into a block from outside the block may have occurred.   [9000]
output.for(120) : Error: An unterminated block exists.
 if(nkomp.eq.2)then
output.for(111) : Error: An unterminated block exists.
 if (find.eq.'H') then
Error executing df.exe.
output.obj - 4 error(s), 3 warning(s)

С незаконченными блоками IF понятно, только интересно куда могли деться их ENDIF? И что за многоточия, что под ними кроется? Или там действительно куска кода не хватает?
А вот с BLOCK BLOCKDATA мне совсем не понятно, я с этим не сталкивался. Нашел кое-что в Бартеньеве, но мало что понял.

И еще в pureread есть ошибки в коде. Но с ними позже, может  с ними станет яснее, когда с output получится разобраться.


Присоединённый файл ( Кол-во скачиваний: 4 )
 output.for 6,72 Kb

Про многоточие спроси у авторов. (на фортране вроде как нет многоточия)
Одного endif, по-видимому, не хватает.
Может так?



А на самом деле, чтобы надежно ловить подобные и другие опусы нужно иметь для всей программы результаты тестового расчета !!!

Это сообщение отредактировал(а) FCM - 20.5.2009, 17:27

Вы имеете ввиду тестовый расчет программы, с того времени когда она работала? Ведь сейчас не сделать, т.к. не компилируется.

Ну а вот эта ошибка

Error: Syntax error, found '.' when expecting one of: <LABEL> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE CHARACTER ...

о чем говорит? И как от нее избавиться можно?

А, все, разобрался -  эта ошибка от этих многоточий. Убрал их, все ушло.
Так, теперь последний файл pureread.for

Тут интересуют вот эти две ошибки и им подобные

C:\pureread.for(61) : Error: This name has already been used as an external function name.   [TM]
     TM(I)=TMJA
------------^
C:\pureread.for(61) : Error: This function, which is specified as the left side of an assignment statement, is invalid.   [TM]
     TM(I)=TMJA

Чаго это он ругается?

И еще вот эти

C:\pureread.for(35) : Error: This label has not been defined as a FORMAT label.   [903]
 IF (NEG.NE.0) READ(NEG,903)  KUERZ(I),TKR(I),PKR(I),
-------------------------------^
C:\pureread.for(35) : Error: Constants and expressions are invalid in read-only I/O lists.   [KUERZ]
 IF (NEG.NE.0) READ(NEG,903)  KUERZ(I),TKR(I),PKR(I),
-------------------------------------^
C:\pureread.for(36) : Error: Constants and expressions are invalid in read-only I/O lists.   [INK]
     >    OMEGA(I),(AM(J,I),J=1,3),(ink(j,i),j=1,8),NAM(I)

Остальные ошибки (неопределенная ссылка, незаконченный блок и опять эти многоточия) вроде понятны.

Файлик прикрепил.



Присоединённый файл ( Кол-во скачиваний: 2 )
 pureread.for 2,69 Kb

Прежде всего, следует иметь ввиду, что программы на старом фортране интенсивно используют  всякие неявно выполняемые вещи, среди которых самую большую неприятность (источник трудно диагностируемых ошибок) представляет  неявное присвоение типов. (В современном фортране рекомендуется отсекать это безобразие инструкцией IMPLICIT NONE) 



Массив TM не определен в программе, но поскольку TM неявно присвоен тип REAL*8, то компилятор думает, что TM(I) это функция, но не может найти определение функции  с таким именем.
Еще не определены массивы INK, DHM.
Надо до исполняемых инструкций вставить что-нибудь типа

REAL*4    DHM(NKOMP), TM(NKOMP)
INTEGER  INK(MK,NKOMP)

(размеры  и типы массивов я выбрал исходя из контекста - перепроверь)





Это сообщение отредактировал(а) FCM - 23.5.2009, 12:04

Под меткой 903 должен быть определен формат считывания инструкцией FORMAT.
Но таковой в исходнике нет. В приципе можно попробовать в READ вместо 903 указать * .




Наверное потому, что
1) KUERZ является параметром процедуры, а тут вдруг считывается из файла.
2) Явное опрделение INK, предложенное выше, должно устранить эту ошибку.

Кроме того непонятно откуда READ производит считывание. Нужно же предварительно открыть файл, а после считывания закрыть. Возможно, это READ создатели планировали к удалению из программы?

Ну и для цикла  DO 3000 должен быть указана инструкция 
 3000 CONTINUE
причем по -видимому предпоследней (перед END) в подпрограмме . 

Это сообщение отредактировал(а) FCM - 22.5.2009, 19:25

Спасибо за терепение и направление по пути истинному Надеюсь все получится. Размеры и типы массивов вроде правильны.

Все сделал, все ошибки ушли, кроме одной с этим KUERZ. Метку 903 в READ я пока зменил на *.

Что касается самого KUERZ - это порядковый номер вещества в базе данных. И по идее (насколько я понимаю) он должен считываться из файла poly.in

Этот файл был в купе со всей программой, прикрепляю его сюда.

Номер вещества должен быть в 4 строке текстового файла (COMP), и в данном случае, это вроде бы среднее число - 16902. Постараюсь еще уточнить.

Присоединённый файл ( Кол-во скачиваний: 3 )
 poly.in 1,27 Kb

Нельзя параметр KUERZ, являющийся формальным параметром процедуры, изменять внутри процедуры "левым" образом.
Возможно ,  изначально KUERZ считывался из файла, потом считывание перенесли в другую процедуру, а  KUERZ сделали параметром процедуры, но до ума дело в pureread.for не довели. Чтобы понять это, нужно видеть, где и как вызывается процедура из pureread.for. В выложенных ранее файлах она не вызывается. 



Это сообщение отредактировал(а) FCM - 26.5.2009, 14:01

Хм... Вероятно в этой подпрограмме (pinread.for)

На всякий случай, все файлы программы + текстовый файл в архиве тут выложу. Может с ними картина яснее будет.




Присоединённый файл ( Кол-во скачиваний: 5 )
 Prog.rar 12,16 Kb

По-моему подпрограмма purere10 из pureread.for нигде не используется.
Проверь это сам с помощью поиска в каждом из исходников.
Зато там используется много подпрограмм (FILESPLT, TRIMLEN, DDBFILE. FILECON, RUNSTR, IPAS, READINP И ДР.  ) неизвестно откуда.
Возможно они входят в некоторую библиотеку, которая компоновалась вместе с данным проектом.
Либо использовался незнакомый мне компилятор. Известно, какая ОперационнаяСистема и какой компилятор использовался у них?

Также (компилятором) замечено, что размеры некоторых одноименных COMMON-блоков, идентичных по объявленным в них переменным, в разных процедурах различается. По-видимому, имеет место несоответствие типов (например, одна и та же переменная включаемая в один и тот же COMMON-блок в одной процедуре заявлена как REAL*8, а в другой процедуре как REAL*4 ( то же касается INTEGER*4 и INTEGER*2) )

Это сообщение отредактировал(а) FCM - 28.5.2009, 08:41

Да, в приведенных  (переданных мне) файлах они действительно не вызываются.

Вот  что мне удалось выяснить. Используемые подпрограммы не используются какими-то специфичными библиотеками, а сами по себе являются специфичными подпрограммами. Т.е. тут не одна такая программа, а несколько, которые постоянно модифицируются и служат для разных целей, но в принципе работают одинакого и все используют одни и те же подпрограммы. Я докопался до архива программ и нашел все, что вызываются в программе.
Программа писалась на Digital Fortran 6.1 (наверное там и компилировалась???)
Мне по-видимому передали только модифицированные файлы программы, которые соответствуют другой модели (т.е. которой мне надо пользоваться) вычисления. Поэтому в тех других подпрограммах ошибок не должно быть. Их, по идее, не должно быть и в этих несколких модифицированных файлах которые мне передали (перечислены в первом посте), т.к. эта модифицированная программа работала и с ее помощью была написана диссертация. Может быть случайно кто-то что-то немного наковырял, других версий у меня нету.

Так вот подпрограммы purere10 и pinread вызываются в READINP. 



Так на данный момент надо выяснить где вызывается процедура использующая параметр KUERZ?Немного запутался в терминологии: процедура, т.е. здесь это подпрограмма purere10?

Прикалываю этот READINP

P.S. Так же нашел эту диссертацию, там есть небольшое описание структуры программы. Попробую дособирать еще несколько подпрограмм, которые там озвучены и собрать их в проекты. А проекты в одну Workspace.

Да, процедура из файла pureread.for - это подпрограмма purere10. (Процедурой удобно называть обобщенно либо подпрограмму либо функцию). Поскольку ты пишешь, что она вызвается в процедуре READINP, то видимо по исходнику READINP и можно выяснить замысел авторов.
Но процедуру READINP тебе выложить не удалось, так что не могу ее посмотреть.


Имеются ввиду старые версии Visual Fortran (Digital Visual Fortran 5.X или Compaq Visual Fortran 6.Х) ?

Это сообщение отредактировал(а) FCM - 28.5.2009, 16:53

Ой и правда..

Вот.

Присоединённый файл ( Кол-во скачиваний: 3 )
 readinp.for 2,90 Kb

Как видим  PURERE10 вызывается в READINP

стр 19:  CALL PURERE10 (NKOMP,KUERZ,NEG,NAG,*9998)

стр 46:   CALL PURERE10 (NKOMP,KUERZ,0,NAG,*9998)

Тут надо подумать , каждый вызов предполагает свой режим работы PURERE10, один из которых может включать "проблемное" считывание. 

Это сообщение отредактировал(а) FCM - 28.5.2009, 17:34

Ну те процедуры, что используются в output все нашел.

А про чтение из неоткрытого файла можно подробнее?

Я подредактировал предыдущее сообщение  - пока неясно, что делать с чтением в PURERE10



Насчет неоткрытого файла я погорячился - он открывается в output.for


Ну вот проблема со считыванием KUERZ в PURERE10. KUERZ - является параметром процедуры и и возникает проблема при считывании KUERZ из файла, запрограммированное  внутри процедуры.

Это сообщение отредактировал(а) FCM - 28.5.2009, 18:20

Если раскоментировать строку
DIMENSION KUERZ(NKOMP)
в начале процедуры PURERE10
то компилятор к считыванию KUERZ относится нормально.

Но где определен формат с меткой 903 - это вопрос.

О, вот откопал старый файлик. То есть по идее из него должны были делать этот модифицированный. Теперь пытаюсь разобраться, что изменяли..
Там в конце как раз есть 903 строка с определением формата.

Присоединённый файл ( Кол-во скачиваний: 2 )
 purere10.for 4,03 Kb

Обрати внимание, что во первой (т.е. которую ты выложил первой) версии, за считывание отвечает код

а во второй версии

для второй версии имеется подходящий формат
 
где первое число предполагается целым (I5), затем предполагается 5 пробелов (5X), затем 6 вещественных чисел в фиксированном формате (F10.0), перевод строки (/), 3 вещественных числа фикс формата (F10.0), символ или символьная строка (A).

Т.е. видим, чтоr код считывание отличается и формат должен соответствующим образом отличаться.
Но в конечном счете некоторые детали формата более менее однозначно можно установить по реальному содержанию считываемого файла.
Для начала лучше проанализировать считываемый файл для второй версии с известным форматом.
По моему ранее выложенный файл poly.in не соответствует коду считывания ни в первом, ни во втором случаях - проверь по типам и количеству считываемых элементов. (Может этот файл считывается в другом месте другой поцедурой?)


Это сообщение отредактировал(а) FCM - 30.5.2009, 15:46

Мда.. задачка. 
poly.in должен считываться в одном из тех файлов, что я привел. Так как это как раз и относится к модификации программы, а все модифицированные файлы мне дали. Может быть в pinread?

Постараюсь пока отыскать соответствующий считываемый файл для pereread.

В коде не могу понять, как он находит файл который нужно считывать? Я делал только когда через оператор OPEN, например 

В главной программе (output.for) есть строки


Затем NEG (номер устройства ввода/вывода) передается в качестве параметра в READINP а оттуда в PURERE10.
Т.е. файл открывается  в главной программе, а имя файла  определяется  вышеприведенными строками.


Это сообщение отредактировал(а) FCM - 2.6.2009, 19:00

Аха, понятно. ТО есть все равно где файл открывать. Ну значит, по идее, надо найти файл PSRK.in, что бы понять формат считвания.

Но вот вопрос, где же этот poly.in считывается, непонятно. Может удастся еще что-нить в архивах найти..

Ну, в общем, отпишусь. Благодарю, в любом случае

Я вернулся   Все оказалось немного сложнее, чем я думал, с одной стороны, с другой - проще.
Вобщем, есть некий большой блок программ, независимых друг от друга - проект, а в нем собрание всяких программ (Назову это все оригинальным кодом) С одной из которых я работаю. Так вот этот большой оригинальный код несколько раз актуализировался (легкие изменения), а про мою часть забыли, соответственно, помимо того, что она была в свое время модернизирована (уже отличалась от оригинального когда), так со временем еще от него и "отстала", устарела.

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



Либо, если из Fortran запускаю исходник (F5)



О чем это говорит? В чем проблема?




Это сообщение отредактировал(а) MetalHeart - 11.6.2009, 19:38

При диагностике Visual Fortran run-time error указаны процедуры и в них строки, где возникли проблемы:
RQIPIN строка 20
PSRK    строка 98.
Посмотри, что там находится.

Угу, спасибо. Еще вопрос, общего характера. В фортране строки можно как-то автоматически найти или только самому отсчитывать (98)?

Visual Fortran'ом  ты же пользуешься под Visual Studio, в редакторе которой внизу где-то всегда отображается строка и колонка расположения курсора. Кроме того можно нажать Ctrl+G   и указать строку, на которую хочешь перейти.

По-видимому в 98 строке  PSRK вызывается процедура RQIPIN, в 20-ой строке которой есть проблема

Это сообщение отредактировал(а) FCM - 12.6.2009, 20:03