|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun May 10, 2020 4:04 pm Post subject: Compiler/Linker question |
|
|
If I have a routine that contains a declaration that reads either :
Code: | EXTERNAL ABCD
.
or
.
INTEGER,EXTERNAL:: ABCD
|
and the routine in which this appears does not reference the external ABCD in any way, will ABCD be required to be present as an object or in a .lib or .dll at link time? |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun May 10, 2020 10:29 pm Post subject: |
|
|
I've had a go at this, and FTN95 reports that the variable is unused as a warning, and using -LGO the executable seems to run OK. This came as a surprise to me, because I was expecting a report that there was a missing reference.
(Edit) It used to be said that you should not use unnamed BLOCK DATA routines but should name it/them and include the name(s) in EXTERNAL statements so that the compiler would report if the routine(s) had been omitted. I used so many compilers that were subset and didn't support BLOCK DATA that I never used it, and I see that BLOCK DATA is no longer favoured anyway. The need to initialise or reinitialise large data structures still exists, and BLOCK DATA or compiler initialisation only works once. If I have to initialise and reinitialse then I do it with executable assignment statements in a subroutine that I name BLOCKDATA!
E |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon May 11, 2020 2:29 pm Post subject: |
|
|
Eddie, thanks for the test and your observations.
This has nothing to do with BLOCK DATA (I do use it, but not as you described).
My interest is only in the actual code. For example, if I have 5 or 10 routines in a file, compile it, place it in a library, and link to one of them, all of them are loaded. I'm looking to see if the same phenomena exists if I have an EXTERNAL declaration to that routine, but the routine is never called (it is an excessive declaration).
Over the years, these have crept into the code, and I am wondering , while I have some time now, whether to invest time in cleaning these up. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue May 12, 2020 3:40 pm Post subject: |
|
|
wahorger,
if library is used with the meaning archive (as opposed to import library), then I would like to point to option /mklib which "generates a static library containing a separate object for each function or subroutine" (quoted from ftn95 online help).
This option is, however, only available for WIN32.
Wouldn't that help in the sample you mentioned?
Regards,
Dietmar |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed May 13, 2020 12:57 am Post subject: |
|
|
Dietmar, I will certainly take a look at this, although I think the question still remains whether an unused EXTERNAL will cause the module to be linked in.
Bill |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed May 13, 2020 10:35 am Post subject: |
|
|
wahorger,
I suspect that linking against libraries built with/mklib will prevent a routine declared as external but never called from being "loaded" into the executable. Please look at the souces main.for
Code: |
integer*4 x,y,z
external mult
x=2
y=3
write(*,*) 'x=',x,' y=',y
call sum(x,y,z)
write(*,*) 'sum: z=',z
end
|
and libsrc.for
Code: |
subroutine sum(a,b,c)
integer*4 a,b,c
c=a+b
end
subroutine mult(a,b,c)
integer*4 a,b,c
c=a*b
end
|
. Using script build.bat
Code: |
@echo off
setlocal
SET DEBUG_OPT=/debug
ftn95 %DEBUG_OPT% libsrc.for
slink libsrc1.lnk
ftn95 %DEBUG_OPT% libsrc.for /mklib
ftn95 %DEBUG_OPT% main.for
slink main.lnk
slink main1.lnk
endlocal
|
archive libsrc.lib is built with /mklib, archive libsrc1.lib is built without /mklib, main.exe is linked against libsrc.lib, main1.exe is linked against libsrc1.lib. Looking into both executables via a hex editor you see that mult is not contained in main.exe, but in main1.exe. You might also want to use commands
Code: |
dumpbin main.exe /all
dumpbin main1.exe /all
|
and see that string
Code: |
SECT1 notype () External | _MULT
|
does not occur in the output of the first dumpbin command, but in that of the second.
The lnk files used are main.lnk
Code: |
lo main
lo libsrc.lib
file main.exe
|
, main1.lnk
Code: |
lo main
lo libsrc1.lib
file main1.exe
|
and libsrc1.lnk
Code: |
archive libsrc1.lib
addobj libsrc.obj
file
|
Regards
Dietmar |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed May 13, 2020 2:35 pm Post subject: |
|
|
Dietmar,
Thanks for the additional explanation. I looked up /mklib and I already use SLIM to build my library.
Since my library is built using SLIM, I finally set aside some time for this. I generated a couple of test cases and inserted them into my compilations. I had a couple of questions to answer. I hope others may find this useful.
If I have an EXTERNAL declaration, but never reference the containing routine in the compilation of the containing module/routine, there is no attempt to link that EXTERNAL into the executable. This is good! One less thing to look for (until final clean-up).
If I have a subroutine/function that exists in a file being compiled, yet the routine is never referenced, does it get loaded into the resultant executable? The answer is yes!
This is beneficial to know because as one proceeds in development, sometimes a utility function (or group of them) may be coalesced as differently named routines. I know I have several of these, so I should search them out, especially if they have any large, static data declarations; these will take up room in the executable for no purpose. I have over 1500 individual routines in over 300 files to search through. I may have to write a tool.....
Thanks,
Bill |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|