Welcome to our forums
Hello When trying to compile a very large program (source code primarily in one large file) in debug mode with the /debug compiler option, it fails with a message that the object module is corrupt. Is there anything I can try? Louis
First delete the object file. This is the file with the extension .obj.
Then try to compile the source file by running the compiler FTN95. Try without any compiler options first and see if any compilation errors are reported.
In the worst case, split the large file into small parts taking (say) a few hundred lines at a time. You must put the whole of the main program in one file. Each module and subprogram could have a file each.
Compile each small file one at a time.
Thanks Paul The source file compiles without any problems if I do not use the debug flag. Is the size of the source file the issue here? Its just under 165,000 lines of code. Would splitting it up into smaller files solve this problem? Louis
The size of the file will not be a problem for the compiler but smaller files will help you to locate what is going wrong.
Are you using Plato or compiling from a command prompt?
Thanks I use the command line. Are you suggesting that using smaller files will get round the corrupt object file problem? I'm not really clear why this is happening. Louis
No. Smaller files just help you to locate the bug that is causing the problem.
If your program fails to compile (has compilation errors) then the object file is created but is marked as corrupt. So you need to find the bug or bugs in your code.
Under normal circumstances the compiler will report the compilation errors quite clearly. So either there is some wrong with how you are running FTN95 or you have very strange code.
Does FTN95 report simple errors such as a missing bracket?
Quoted from ljfarrugia Thanks Paul The source file compiles without any problems if I do not use the debug flag. Is the size of the source file the issue here? Its just under 165,000 lines of code. Would splitting it up into smaller files solve this problem?
Object files are larger when compiled with the debug flag.
Louis, are you aware that there are available utility programs, usually named fsplit or f90split, that can take your large source file as input and place each subprogram in it into a separate file?
See for example, https://people.math.sc.edu/Burkardt/f_src/f90split/f90split.html .
Hello Still trying to track source of the problem. One thing I don't understand is why some .MOD files for modules do not seem to be created and which may be the cause
The code below is taken from this huge program (incidentally not written by myself). When it is compiled and linked (on command line) the .EXE file is created but not a .MOD file for the module. This is the same when the large code sources is compiled. All the other .MOD files seem to be there. Is this the expected behaviour?
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
PROGRAM MAIN
call pla351
end program main
SUBROUTINE PLA351
C * THIS ROUTINE IMPLEMENTS THE CHARGE FLIPPING CONCEPT - Oszlanyi et al.
USE com3
end
There must be a mod file somewhere otherwise the compiler would report it as missing.
com3 does not have object code in a .obj file because it does not contain any executable code.
I think that the module/file name that Louis chose is clashing with one of the predefined device names in MSDOS/Windows. COM1, COM2, COM3, COM4 used to be serial communications ports (for RS232 devices such as modems, terminals, mice and printers).
Even on today's PCs, one can plug in a GPS receiver into a USB port and the receiver can send GPS data to the PC as if the USB port were a 4800 baud serial port.
Here is an example.
s:\lang\ftn95>type fcom.f90
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
s:\lang\ftn95>copy fcom.f90 com3.f90
The system cannot find the file specified.
0 file(s) copied.
s:\lang\ftn95>
Note that the file copy failed because the destination file name began with 'com3'.
A slightly different example, this time using the device name CON:
s:\lang\ftn95>copy fcom.f90 con.f90
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
1 file(s) copied.
s:\lang\ftn95>dir con.*
Directory of \\.
File Not Found
This time, the name 'con.f90' got interpreted as the console device CON:, and that is why we see the lines copied to the console rather than to a disk file, and after the copying was completed there is no file on disk with the name of the copy destination.
Hello I wasn't complaining that there was no object file for module COM3, but that there was no .MOD file after compilation. If you are compiling code which spreads over many files, I suppose these mod files are needed for subsequent source file being compiled which use module COM3, which has been defined in another source file.
In any case the comment about the name COM3 seems to be correct. I changed the module name COM3 to COMTHREE and the file COMTHREE.mod now appears after compilation. I wonder if there are other forbidden names for modules? Louis
Dear Paul The compiler did not report that the .MOD file was missing, it just hung up. This was when I created a debug version using the /debug command line flag.
If I created a standard executable without /debug compiler flag, then the compilation ran to completion without reporting any errors. Louis
Quoted from ljfarrugia I wonder if there are other forbidden names for modules?
The limitation on allowable file names is attributable to the operating system, not the Fortran language or the Silverfrost compiler. See https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file , where it says:
'*Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended.* '
I combined your sources in logical order into a single source file:
module com3
implicit none
integer :: itop, ngrid
real :: sthm
end module com3
subroutine pla351()
use com3
implicit none
print *,itop,ngrid,sthm
end
program main
implicit none
call pla351
end program main
The FTN95 compiler crashed when I attempted to compile this file, with the message:
Access Violation
The instruction at address 0045e0f6 attempted to read from location 00000000
My impression always was that compilation may have some limits on source size though it was long ago with 32bit version. So i traditionally have ~10 files with 20-30 k lines max
Try at least to split your file into 3-4. Create batch file where you compile each individual file as usual and LINK as usual. Example
ftn95 A.for /64 /err /no_truncate /free /undef /debug /statistics /binary A.obj >ErrorsForA
ftn95 B.for /64 /err /no_truncate /free /undef /debug /statistics /binary B.obj >ErrorsForB
slink64 A.obj B.obj /file:A.exe >ErrorsForLink
This will make your debugging much more easier since you may not need /undef for all files, only just for few for example graphics part, or any other specific part (though mecej4 warns with /undef or /checkmate this might not be good idea but i never had any problems).
Then you can make batch more complex where there will be commands for compiling with or without debug.
It is quite possible that com3.mod exists but is hidden from view.
Rather than use /debug, put OPTIONS(debug) half way through the file (before a subprogram). If it fails to compile then the problem is in the second half of the file etc.
Dear mecej4 Thats very strange. I took that code and it compiles, links and runs without error. If compiled with /undef/debug it fails of course, because the variables in the module have not been explicitly initialised. Louis
Please state your compiler version, compiler options used, contents of FTN95.CFG and, if not building from the command line, the procedure followed.
I tried several versions of FTN95 (6.35, 7.1, 7.2, 8.65, 8.82) and all of them gave an access violation similar to the following (attempt to read from location 00000000):
Runtime error from program:c:\lang\ftn95v882\ftn95.exe
Access Violation
The instruction at address 0045e0f6 attempted to read from location 00000000
0045de7e process_binary_module(<ptr>void,enum─logical)#1D [+0278]
0045f296 process_use_stmt(<ptr>char,<ref>int) [+02ff]
0040bedd parse_declaration_statement(<ptr>char,int,int,<ref>int) [+2c61]
00414237 handle_token(<ptr>char,int,int,int,int,<ref>int) [+0ea3]
00405ff0 ProcessEntireLine(void) [+06d2]
00406f7a compile(<ptr>char) [+016f]
0040181d main [+058e]
0059a3ce SALFStart [+06ff]
I'm using FTN95 ver 8.82.0 with command line ftn95 *.f /link or ftn95 *.f /link/debug
Quoted from ljfarrugia I'm using FTN95 ver 8.82.0 with command line ftn95 *.f /link or ftn95 *.f /link/debug
This is getting confusing!
The last example that I gave, in the 12th response, starting 'The limitation...', is in free form, so you should have given the file an 'f90' suffix. Secondly, the compiler will not accept the compile and link commands with *.f or *.f90 as the file(s) to use unless you give it an unambiguous name for the output EXE file, and at least one file exists with the specified suffix.
[code]s:\lang\ftn95\tbed>dir Volume in drive S is RAMDISK Volume Serial Number is D208-C000
Directory of s:\lang\ftn95\tbed
11/29/2021 11:17 AM <DIR> . 11/29/2021 11:17 AM <DIR> .. 12/10/2021 06:07 AM 231 xcom3.f 1 File(s) 231 bytes
s:\lang\ftn95\tbed>ftn95 *.f90 /link [FTN95/Win32 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021] *** *.f90 does not match any source files
s:\lang\ftn95\tbed>ftn95 *.f /link [FTN95/Win32 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021] *** /LINK and /LINK_MAP require an explicit file name when a wildcard source file name is used
I can confirm that with 6.35 I get the same result as yourself, but with 8.0 and 8.82 I have no problem