portal. It's new and slick. Maybe this will improve the quality of
google posters.
message body follows:
"Craig Dedo" <cd***@wi.rr.comwrote in message
news:47***********************@roadrunner.com...
<ro************@sun.comwrote in messageWhat does the standard say about linking in general? I think most of
news:11**********************@k79g2000hse.googlegr oups.com...>On Oct 3, 5:41 pm, mich...@athenavisual.com wrote:>>I have a module
MODULE mymodule
***
***
Contains
Function myFunction() result(x)
***
***
Call aSubroutine(****)
End Function
****
****
END MODULE
where aSubroutine is a user supplied subroutine.
my problem is that sometimes the subroutine referenced in the function
above may not be present, in which case the linker complains; other
than writing a dummy subroutine in this case what are my options? what
does the standard say?
Robert Corbett gave a fairly complete answer. See my remarks below for
more detail.
>The following is based on the Fortran 95 standard.
By a chain of logical too long to be worth reproducing
here, the subroutine-name in the CALL statement is
established to be a reference to an external procedure
by item (3) of Section 14.1.2.4.3
(3) If (1) and (2) do not apply, the reference
is to an external procedure with that name.
Section 12.1.2.2 states
An external procedure is a procedure that is defined
by an external subprogram or by a means other than
Fortran.
Based on that, the standard requires the external
subprogram to be part of the program. Therefore,
a Fortran processor can require that there be an
external subprogram with the given name, even if
the CALL statement that references it is never
executed. On the other hand, no constraints would
be violated if such a subroutine is not supplied,
and so a Fortran processor is not required to note
the absence of the subroutine.
Bob Corbett
The standard does not cover the operations of the linker. This is
explicitly excluded by section 1.4 of both the Fortran 95 and Fortran 2003
standards.
Your only options are either:
(1) ignore the warning or error messages from the linker, or
(2) write a dummy subroutine that does nothing.
Of the two options, I very much prefer option (2).
us are
looking backwards at a good chunk of the steep learning-curve that is
standard linking, yet none of us knows it all; it's a problem that
penetrates deeply into the nature of finite-state automata. It's so
complicated in C that it requires someone like Jabba the Hut to
explain.
There's a lot of nuance in #defining and #undefining, and I do not
dispute
Keith Thompson's encyclopedic command of the issue. If I did dispute,
he'd
hand me my ass in any technical discussion.
That said, the purple dinosaur will not tolerate talk of how to link
to c++,
windows, or anything remotely more useful than linux, C's ugly red-
headed
stepchild. You can claim that I'm confused about system-specific
stuff and
portability, but I would remind that ISO C, for all its portability,
goes
*nowhere.*
Then you have fortran and perl, which define themselves off of c. I
think
that the reason that Richard Maine--c.l.f.'s answer to Keith--allows
talk of
more varieties in linking traces itself directly to the standard, but
I
don't know. I do know that c-fortran linking must be a calculus else
interop is a pipe dream. Anyways....
--
wade ward
"Your boyfriend is not my boyfriend, doll."