Re: strange linking problem
- From: Richard E Maine <nospam@xxxxxxxxxxxxx>
- Date: Thu, 28 Apr 2005 09:23:02 -0700
In article <1114703379.735008.294480@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
nicolasbock@xxxxxxxxx wrote:
> Thanks Richard, I didn't know that. I usually use C, and since strings
> don't exist there I sort of assumed that to be similar in f90.
Fortran arrays of characters are pretty direct analogues to those of C.
In fact, it is sometimes more convenient to use arrays of characters
instead of strings when interfacing to C. But many character operations
in Fortran are more "naturally" done with character strings instead of
arrays. So most commonly, you'll see character strings instead of
character arrays in Fortran (like your example was using) unless there
are special circumstances.
> As far as I know, the linker goes through the object
> files and looks for unsatisfied references to functions and variables.
> Then it looks through the libraries and tries to satisfy those
> references by linking code from the libraries into the executable. If
> that's correct, then I don't understand how the linker does not either
> 1) find a reference to "test", link that in from the library and
> everyone's happy, or 2) see that "test" is not satisfied and give me an
> error. The fact that it does not complain suggests that the linker
> indeed is linking something into the executable from the library. But
> apparently something that does not contain the literal string that I
> assigned to "test".
>
> Could someone explain this to me?
I'll try. For procedures (both functions and subroutines), you are
right, but variables are different. For a procedure, things are
relatively simple (in this regard). The linker sees 2 kinds of things:
there are references to a procedure and there is a separate thing is the
procedure itself. If you have references with no corresponding
procedure, that is an error.
For data, however, it is possible to have multiple references to a data
area, with nothing that actually is uniquely the data area itself. This
is typical of non-initialized data areas. All that the linker sees is
that there should be a data area of a certain size and a certain name.
If something defines the area, then fine, that definition gets used. But
if nothing otherwise defines the data area, the linker will allocate an
an appropriate chunk of memory. This is not an error, and indeed is
quite typical for COMMON blocks.
I forget all the right terminology, but the "references" that the linker
sees for the variable "test" here are probably of this type, where you
won't get an error for a lack of other definition. The linker doesn't
tend to look in libraries for this kind of reference.
As alluded to by others, this used to be quite a widespread problem with
COMMON in f77 and earlier days. Modules are less prone to the problem,
but it can still happen (only when the modules have no referenced
procedures).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.
- Follow-Ups:
- Re: strange linking problem
- From: glen herrmannsfeldt
- Re: strange linking problem
- References:
- strange linking problem
- From: nicolasbock
- Re: strange linking problem
- From: Richard E Maine
- Re: strange linking problem
- From: nicolasbock
- strange linking problem
- Prev by Date: Re: strange linking problem
- Next by Date: Re: why doesn't this compile ?
- Previous by thread: Re: strange linking problem
- Next by thread: Re: strange linking problem
- Index(es):
Relevant Pages
|
