Re: Regarding Fortran Compiler Characteristics

[Tobias Burnus]

Hello Ralf,

As a quick summary:

a) I think AC_FC_MAIN/AC_F77_MAIN does the right thing, but the
documentation - especially the example - is misleading. (And it is of no
harm but of little use with all(?) newer compilers.)

b) A test to find out how the library initialization function is called
would be useful.


Ralf Wildenhues wrote:
>> There one can find for AC_FC_MAIN/AC_F77_MAIN:
>> [...]
>>           int F77_MAIN(int argc, char *argv[]);
>>     
> AFAIU you are saying that for these compilers: [....]
>
>
> calling this special function is not necessary, but it also is no
> problem at all if the user does this; right?
>   

Well, not quite. I think using

FC_MAIN(argc, argv);

will presumably never fully work.

a) Assuming that you don't have a Fortran main PROGRAM but only a stack
of procedures written in Fortran. Then MAIN__ is not defined and one
tries to call an undefined symbol. (linking error)

b) The call will work, if you have a Fortran main PROGRAM but then the
arguments are likely to be ignored. Additionally, the call might be not
possible, if the Fortran compiler generates main(argc,argv) alongside
MAIN__() as some compilers do. Besides, it does not make conceptionally
sense to have a Fortran main PROGRAM and, e.g., a C "main()" program.

c) The symbol FC_MAIN can be useful, if the you have a Fortran library
which also contains a "main()", which calls e.g. MAIN__ as you then get
linking errors, unless you provide a stub. I think this is the only real
legitimate use of FC_MAIN. With all compilers I know, this is not an
issue as they either have "main" in a separate library, in a separate .o
file or generate main() along MAIN__. However, I don't want to rule out
that such compilers still exists, which have main() in the same library
as the rest.


Thus regarding FC_MAIN, I think the configure check and also the
documentation is OK, except for the example where passing "(argc, argv)"
is misleading: The arguments are likely to get ignored and calling
MAIN__ is also a doubtful exercise. (Do you have a C or a Fortran main
program? If the former, one should change PROGRAM to SUBROUTINE in Fortran.)


* * *

The other point was: It would be indeed useful to provide an AC_* to
find out which initialization function to call, if one has e.g. a C main
program and calls some Fortran routines. That is rather an omission that
a bug of autoconf, but related to the misleading MAIN__(argc,argv)
example above. And to the misleading text in the comment, see below.

* * *

> Well, there are many more Fortran compilers and systems out there,
> and the MAIN__ was definitely required for some of them at some point.
>   
Well, MAIN__ still exists in many compilers do to backward
compatibility; I think only NAG f95 does not have it.

I think is goes back to the time when it was seen to be easier to have a
complicated "main()" function in the library which does some
initialization and then calls the actual Fortran program ("MAIN__"). I
don't quite see why they not simply generated a "main()" for the Fortran
program and then did as first action an initialization call to the
library. But due to this history, most compilers have a MAIN__.

> The macro has this in the comment:
>
> # What is technically happening is that the Fortran libraries provide
> # their own main() function, which usually initializes Fortran I/O and
> # similar stuff, and then calls MAIN__, which is the entry point of
> # your program.
>   
That is still the case, except that main() might not only be in the
library, but can also be in another .o file or be generated along the
MAIN__ function.

> # Usually, a C program will override this with its own
> # main() routine, but the linker sometimes complain if you don't
> # provide a dummy (never-called) MAIN__ routine anyway.
>   
I think that does not happen anymore with newer Fortran libraries; they
usually have "main()" not in the standard lib<fortran>.{a,so} file but
separately. That means if you link lib<fortran>.so along with some
Fortran routines (*.o) you should not have the need to provide a MAIN__
stub.

> # Of course, programs that want to allow Fortran subroutines to do
> # I/O, etcetera, should call their main routine MAIN__() (or whatever)
> # instead of main().  A separate autoconf test (_AC_FC_MAIN) checks
> # for the routine to use in this case (since the semantics of the test
> # are slightly different).  To link to e.g. purely numerical
> # libraries, this is normally not necessary, however, and most C/C++
> # programs are reluctant to turn over so much control to Fortran.  =)

That is quite incomprehensible and I think at least partially wrong. If
I understand it correctly, it is about having a "main()" which is
written e.g. in C but one accesses a few Fortran procedures
(subroutines, functions). In this case MAIN__ should not be available
(no Fortran main PROGRAM but just SUBROUTINEs/FUNCTIONs). And as written
above, the library is initialized using different calls and not by a
call to MAIN__ (which was never part of the library).


> # The name variants we check for are (in order):
> #   MAIN__ (g77, MAIN__ required on some systems; IRIX, MAIN__ optional)
> #   MAIN_, __main (SunOS)
> #   MAIN _MAIN __MAIN main_ main__ _main (we follow DDD and try these too)
>   

That looks ok. You can also add gfortran, sunf95, ifort to the list
which have a MAIN__; but at least those three don't need a stub MAIN__.

> Also, have you tried or looked at the Sun Studio, IBM, Portland,
> PathScale Fortran compilers?
>   

No, I didn't check the documentation. I know that Sun Studio puts the
PROGRAM into MAIN__ (for backward compatibility) and generates a
"main()" alongside. Conceptionally it does not make any sense to have
(a) a MAIN__ without having a Fortran main PROGRAM and (b) passing the
arguments to MAIN__ to initialize the Fortran library.

For the name of the initialization functions, one should look at the
documentation; I'm sure they have some function to do so.

> If OTOH calling this other main function poses a problem for gfortran,
> then we would need to do something about this (most likely: file a bug
> report with gfortran for breaking backward compatibility :-).
>   

Well, calling MAIN__ at some arbitrary point poses a problem for all
Fortran compilers which I know as it is expected that MAIN__ is only
called once at the beginning of the program and not several times. (I'm
sure that one can also produce some strange results if one calls
"main()" in C several times.) Though it probably won't break in the
library but in the user code. And I sincerely doubt that there was any
Fortran compiler which generated a MAIN__ which read the argc/argv
arguments - or at least I cannot see any use of doing so. It does not
make sense if the actual "main()" is in the library.

Tobias