ddh@hare.cdc.com (Dan Horsfall) (11/06/90)
This subject was beaten to death my myself and James Craig Burley a
while back, with not much resolved between us. For those who have
the following problem, here is a potential solution.
Problem: How to load a BLOCK DATA subprogram from a LIBRARY.
(This can be a problem since you can't CALL a block data subprogram
in the usual sense, thus the loader/linker process ofmatching
external references to entry points frequently does not work.)
Flash of insight here: Thinking that a good optimizing compiler does
NOT allocate storage for a variable which appears ONLY in a type
declaration statement, perhaps some compilers also do not generate
external references for symbols that appear ONLY in EXTERNAL statements.
To force an external reference, the symbol must be USED in a manner
that forces it to exist.
Therefore, to those of you who wish to load block data from a library,
try this:
PROGRAM FOO
EXTERNAL BDATA <- same as before
...
CALL INIT( BDATA ) <- pass address to some routine
... etc
SUBROUTINE INIT <- the called routine need not have an
[ or SUBROUTINE INIT() ] argument, but could have one for
[ or SUBROUTINE INIT( BD ) ] cosmetics, depending on your style
requirements and compiler.
Now, the compiler thinks that the address of bdata must in fact be passed
to init -- which may or may not eve define the argument, and obviously
shouldn't reference it/them. This works on MIPS-based f77, and is worth
a try on others.
No flames, please, if this doesn't work for you.
--
Horse
+ Control Data Corporation
Dan Horsfall +1-612-482-4622 + 4201 Lexington Ave North
Internet ddh@dash.udev.cdc.com + Arden Hills MN 55126 USA BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (11/07/90)
In article <28325@shamash.cdc.com>, ddh@hare.cdc.com (Dan Horsfall) writes: >Problem: How to load a BLOCK DATA subprogram from a LIBRARY. > (This can be a problem since you can't CALL a block data subprogram > in the usual sense, thus the loader/linker process ofmatching > external references to entry points frequently does not work.) > I believe the original question here involved an unresolved external in a program compiled using an old version of MS Fortran. I didn't realize that a BLOCK DATA subroutine was involved or I would have responded sooner. I learned that there was some kind of bug in MS-Fortran handling of BLOCK DATA subroutines. (MS tech support called it an 'instability'.) I haven't used MS Fortran in a long time, but here is a note from my files. (5) Note to programmers: This diskette contains an execution module which should run on most DOS systems. It should not be necessary to recompile the program. If for some reason the program must be recompiled, the following precaution should be heeded. MM contains a BLOCK DATA subroutine which, because of a peculiarity in version 3.2 of MS-FORTRAN, must be stored in a separate file, compiled separately, and must precede the main program in the LINK phase. Both the source and object code files for this subroutine are included (MMBLOCK.FOR and MMBLOCK.OBJ). Earlier or later releases of MS-FORTRAN may not require this precaution, in which case MMBLOCK may be added to the source file MMPC.FOR. Check with MICROSOFT technical support for details. Failure to compile and link as described here causes peculiar errors during execution which appear to be unrelated to the BLOCK DATA subroutine. When I say 'must precede the main program in the link phase', I mean that when you list the names of the object code files, you put the file containing the BLOCK DATA subroutine first in the list. I hope this helps. Barbara Vaughan
v087mxgb@ubvmsa.cc.buffalo.edu (Shawn E Thompson) (11/07/90)
no no, you ARE correct... my original question was about EXTERNAL statement, there was no BLOCK DATA involved....thanks for help though! st
dik@cwi.nl (Dik T. Winter) (11/07/90)
In article <28325@shamash.cdc.com> ddh@dash.udev.cdc.com (Dan Horsfall) writes: About a scheme that forces loading of a block data subprogram with most linker/compiler versions. But: > SUBROUTINE INIT <- the called routine need not have an > [ or SUBROUTINE INIT() ] argument, but could have one for > [ or SUBROUTINE INIT( BD ) ] cosmetics, depending on your style > requirements and compiler. By all means: include the argument (although it is not used). Without argument it will fail on a number of platforms. (Those where the linker checks for argument conformance and argument count. They do exist.) I can still imagine platforms where this will fail: 1. The compiler may decide a different naming convention targeted to the linker for the different types of subprograms. 2. The compiler may decide not to include an entry point in the object code for a BLOCK DATA subprogram. Both can constitute a valid implementation of Fortran 77. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl