View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Tue Jul 03, 2018 1:16 am Post subject: Bad SLINK64 diagnostics |
|
|
When compiling numerous fortran source files using BAT file method and at the end SLINK64 them together, the linker does not detect missing OBJ file if one of source files had error. Linker reports the same message "Creating executable file FILENAME.exe" as if all was OK and just does not produce any EXE files. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Tue Jul 03, 2018 7:03 am Post subject: |
|
|
I have made a note that this needs checking out. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Tue Jul 03, 2018 7:15 am Post subject: |
|
|
I have not seen this happen, and it would help if Dan would post the contents of his batch file.
If the linker command in the batch file explicitly contains the name of an OBJ file that is not present, the linker will abort with a message immediately, without producing an EXE. If the linker command specifies *.OBJ, an EXE is produced but a message about undefined external symbols is issued; the EXE will start running but issue a pop-up and quit when one of the missing routines is called. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Tue Jul 03, 2018 9:20 am Post subject: |
|
|
After creating all obj files from the Fortran source files 1.for .... 50.for the link command is
Code: | slink64 1.obj 2.obj 3.obj 4.obj 5.obj 6.obj 7.obj ... 50.dll /windows /file:Run.exe >RunLinkComments |
Yes, the linker aborts if some of these OBJ files are missing. Unfortunately the hint of quick aborting i of course do not notice because SLINK64 goes in BAT file after all these 50 compilations.
But even if SLINK64 aborts i'd still expect even in this case that it better create comments file RunLinkComments (like it does when everything is OK) but it does not create it and i have no clue that bad thing happened and where.
Would be still better if
1) SLINK64 created RunLinkComments and
2) inform which OBJ file is missing.
Instead right now i have to check all compilation comments for all my 1.for, 2.for etc source files and find which failed to compile
The 32 bit SLINK is doing better job here. It stops BAT file and asks "Terminate BAT job /Y/N ?" and you clearly see that something is wrong and
it creates comment file RunLinkComments with the message *** Could not open: 3.obj" |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Jul 03, 2018 1:37 pm Post subject: |
|
|
Dan,
I am not sure if I understood what you meant and what you expected slink64 to do.
If you redirect the output of slink64 to file RunLinkComments then you will not see it unless you open file RunLinkComments (which should contain the error message you are interested in).
What I do in such a situation (when compiling several sources and linking an exe file) is redirecting the complete output (including error messages) of any tool I'm interested in into one log file and then analysing the log file with respect to possible errors.
In a batch file, say x.bat, you could something like
Code: |
@echo off
setlocal
set LOGFILE=x.log
ftn95 file1.for > %LOGFILE% 2>&1
ftn95 file2.for >> %LOGFILE% 2>&1
slink64 file1.obj file2.obj /file:Run.exe >> %LOGFILE% 2>&1
endlocal
|
Executing x.bat creates a file x.log, which contains possible error messages. E.g.
Code: |
***Object file file1.obj does not exist |
You could use a filter to search x.log for the sequence "***", e.g. the find command. If everything was ok, then no "***" should appear in x.log.
Regards,
Dietmar |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Jul 03, 2018 2:00 pm Post subject: |
|
|
There is another issue in this context: slink64 does not mark resource files (e.g. files of the form *.res) as loaded although they have been.
The following command creates file load_res.exe successfully
Code: |
slink64 load_res_64.obj load_res_64.res /file load_res.EXE
|
. Here load_res_64.obj and load_res_64.res have been created by means of the 64 bit variants of ftn95 and src. The output of the latter command is
Code: |
[SLINK64 v2.03, Copyright (c) Silverfrost Ltd. 2015-2018]
Loading c:\ds\samples\salford_8.30\help_system\salford64\load_res_64.obj
Creating executable file load_res.EXE
|
. Now renaming load_res_64.res to load_res_641.res and executing the command mentioned above again results in
Code: |
[SLINK64 v2.03, Copyright (c) Silverfrost Ltd. 2015-2018]
***Resource file load_res_64.res does not exist
|
showing that slink64 tries to load the res file.
Regards,
Dietmar |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Tue Jul 03, 2018 9:08 pm Post subject: |
|
|
Dietmar,
From the first glance I don't see principal differences in my way versus yours, I do all the same, with minor difference is that I prefer not to create one log file but create each for each Fortran file Code: | FTN95 1.for >compile1log
FTN95 2.for >compile2log | and separate one for linker errors, see my post above. Otherwise the megatons of comments and warnings in my case will be unmanageable even with automatic search patterns with ***. Yet I do not see that slink64 reports ansent obj file while slink clearly reports it. And additionally slink stops bat file in case if error so you will notice that for sure.
With 64 bit linker I missed infinite times the compilation errors and used older exe until I started to delete all older exes and logs at the beginning of bat file.
I will then rephrase my previous message: 32 bit and 64 bit linkers have to be synchronized with the way they handle and report errors, create EXE file, name RES file and manage BAT file execution in case of errors. I find that 32 bit linker was doing more reasonable things then 64 bit one so the additional tricks from programmers side to see the errors will be unnesessary |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Jul 04, 2018 5:44 am Post subject: |
|
|
Dan,
Place a del run.exe at the start of you build.bat file.
I actually use:
del %program%.exe
del *.mod
del *.obj
(is run.exe a good name to use ?) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 04, 2018 10:10 am Post subject: |
|
|
Dan
Are you using v2.03 of SLINK64? |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jul 04, 2018 10:48 am Post subject: |
|
|
Dan,
I am afraid I do not understand why you blame the linker slink64 because slink64 does abort if object files are missing (as you said and which coincides with my experience).
So I think it is the batch file containing the slink/slink64 commands which might cause a problem (I did not yet understand what the problem is in your opinion). It is like mecej4 said: it would help if you posted the batch file.
I use bat files for linking most of my 64 bit applications. I could not reproduce your problem: after having removed an object file needed and executing the link batch file, it stops with the lines "Cntrl-C" and "Terminate BAT job /Y/N ?" as expected. And as I redirect the output of slink64 to an error file within the bat file, I see the "Could not open" error message in the error file.
Note: the "Cntrl-C" comes from slink/slink64 in case of error. ftn95 and scc do not produce a "Cntrl-C" in case of error. You would normally check the outcome of a utility by means of variable ERRORLEVEL. If ftn95/scc is successful, then command ERRORLEVEL is 0, if is unsuccessful then ERRORLEVEL is 1. If slink/slink64 is successful, then ERRORLEVEL is 0. However, if it is not successful, ERRORLEVEL is -1073741510.
Now, if slink64 is called from within the batch file, the batch file pauses with the terminate question because of the "Cntrl-C". If you answer yes, the batch stops, however, if you answer no, then the batch continues. You could make use of this by adding a code sequence
Code: |
if not "%ERRORLEVEL%" == "0" (
echo ERROR %ERRORLEVEL% in link
) else (
echo link successful
)
|
directly after the slink64 call in your batch file to display the outcome of the linking step of your batch file.
Regards,
Dietmar |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jul 04, 2018 10:54 am Post subject: |
|
|
Sorry,
in a line of my last entry the string "command ERRORLEVEL" should read "ERRORLEVEL" only.
Regards,
Dietmar |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Wed Jul 04, 2018 7:24 pm Post subject: |
|
|
Dietmar
I posted all major components of batch file above, the real one is too large to fit here.
Again, my post was about different behavior of SDBG64 vs SDBG. It should be the same.
SRC outputs and syntax in SDBG64/SDBG have to be synchronized too. If this is not possible or not desirable then it has to be explained why.
After that behaviors synchronized or failed to be synchronized by some reasons it has any sense to do any workarounds.
/* My batch files are large and numerous and making them more complex due to necessity keeping both 32 and 64 bit compilations just adds me problems. The problems arise from the code size scaling. Even batch files became very long with time with their numerous exclusions and adjustments. Easy to forget something in long long sheets. If before with small codes the errors were causing loss of just seconds, minutes and may be a day, then today with large code sizes I lose days and weeks. Even up to a month few times. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 04, 2018 9:14 pm Post subject: |
|
|
The resource compiler SRC has not needed any changes for 64 bits. It has always been able to produce 32 bit .obj files and generic .res files.
SLINK64 has been designed to accept the generic .res form of output from SRC.
The result is that for 64 bits, /r is required on the SRC command line and the .res result is loaded via "lo" in SLINK64. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Wed Jul 04, 2018 9:29 pm Post subject: |
|
|
The extension of SRC for 64 bit is different, not the obj like it was before. If this is important, I'll gladly learn, but if not I'd for example prefer not to mess with subtle differences in res and obj no one will remember, will be less exclusions and at the end errors if there will be just one or another but not two. That already caused me losing a day and asking about that in this group.
There exist good analogy for that: who wins in the wars? Those nations which have language where average commands are shorter. Average length of commands: Japanese and German 10+, English 5 and Russian 3.2 symbols. Shorter commands - less they're error prone.
I feel that recent decade my performance dropped several times, small things now take not hours but a week and I make so many errors and forget so many details that this caused me to check myself with all my friends and eventually with the doctor . After no one noticed anything I tend to accept the old theory I did not believe all my life that performance of programmer drops dramatically with the problem size, I thought with time your experience is growing and you should do things faster and faster, but this does not actually helps much. ...Here any irregularity in the compiler for example become a source of much larger scale loss of time. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Jul 05, 2018 2:25 am Post subject: |
|
|
For the SRC difference in generated file extension ... 32bit SLINK picks up the appropriate extension (no need to specify it (that's what it shows in the documentation in examples .
does the same occur with SLINK64 (does it pick up the .res automatically without needing to specify it on the command line ?
I would expect it to (for consistency), but comments by mecej4 on the beta 279 release post seem to indicate otherwise
Dan, Japanese or chinese is the top languag for brevity.
Did you know that they both have a single (ONE) letter symbol which represents a whole %pl command with all parameters included ? :O) _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|