Xref: utzoo comp.lang.fortran:3966 comp.sys.sgi:6381 Path: utzoo!attcan!uunet!know!cs.utexas.edu!tut.cis.ohio-state.edu!uc!shamash!hare!ddh From: ddh@hare.cdc.com (Dan Horsfall) Newsgroups: comp.lang.fortran,comp.sys.sgi Subject: Re: archiving block data subroutines... Message-ID: <27320@shamash.cdc.com> Date: 22 Oct 90 14:42:22 GMT References: <1990Oct22.033107.5159@ux1.cso.uiuc.edu> Sender: news@shamash.cdc.com Reply-To: ddh@dash.udev.cdc.com (Dan Horsfall) Followup-To: comp.lang.fortran Organization: Control Data Corp, Arden Hills, MN Lines: 66 Distribution: In article burley@world.std.com (James C Burley) writes: > In article <1990Oct22.033107.5159@ux1.cso.uiuc.edu> jeffb@aquifer.las.uiuc.edu (Jeffrey Biesiadecki) writes: > > We have a library written in Fortran77 which includes a block data > subroutine. If we use "ar" to archive the object files of the library, > and then try to compile a program using the resulting "lib???.a" file, > everything works fine EXCEPT the block data subroutine is never executed > (that is, the initializations are not made). If the block data object file > is linked in explicitly with the fortran compiler, then the initializations > are done. > Keep in mind here a terminology issue: block data subprograms are not executable. They by definition contain no executable code. They cannot be "called". > Hi back! I know nothing about "ar" or "lib???.a" files. But in Fortran, > there is a specification for forcing the inclusion of a BLOCK DATA program > unit in a program. It is EXTERNAL, believe it or not. For example: > > PROGRAM FOO > EXTERNAL BDATA > COMMON /X/I > PRINT *,I > END > > BLOCK DATA BDATA > COMMON /X/I > DATA I/5/ > END > > Without "EXTERNAL BDATA", the block data program unit must be explicitly > linked with the program, or whatever wording to that affect is appropriate > (since the standard doesn't really talk about linking). With it, the linker > should complain if it can't find a block data program unit named BDATA when > linking FOO, and thus should also pull it in from any library it is > searching. > I beg to differ. EXTERNAL for linking in block data routines is a "fairly common" extension, but is NOT standard. Here's the problem at the loader level: Block data subprograms contain no executable code. Thus, they do not contain an entry point. A while back, some compiler writers figured out that if they added an entry point to a block data routine (which actually makes it executable, tho usually the supporting code is an instant _return). Now, having an entry point makes it resolvable by other routines that declare the same symbol as an external reference. How to do this in a manner that doesn't actually execute the code? Declare the symbol EXTERNAL in some other routine. Not all vendors support this mechanism, but this doesn't mean they are nonconforming. MIPS is one of these; mips makes the sgi box; James Burley's otherwise exemplary solution doesn't apply to you. What you gotta do is force load your block data routines the same way you force load your main program to start the loading process, e.g.: f77 -o xxx main.o bdata.o libx.a ( In our case here, we use f77 -o xxx *.o *.a, and make sure that the right *.o's are available. Kludge, but the only solution.) -- 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