Re: undefined reference to `MAIN__'

[Tobias Burnus <burnus at net-b dot de>]

On 08/25/2009 09:59 AM, chao sun wrote:
> But I 've included the file containing the Fortran main program  and
> it's a fortran program indeed.
>   
Well, the linker believes otherwise. Thus there are two possibilities:
Either you did not include the file or the symbol was eliminated
(optimized away etc.) at some point.

gfortran -o prep_chem_sources  \
>>     prep_chem_sources.a ..//utils/bin/libutils-2.0-opt.a
>> -I/usr/local/include -L/usr/local/lib -lnetcdf


I find it quite unusual to include all *.o files into an *.a file before
linking them. Can you unpack prep_chem_sources.a (mkdir tmp; cd tmp; ar
x ../prep_chem_sources) and check whether the relevant file contains the
symbol MAIN__? For instance by doing
  nm *.o|grep MAIN__
which should show something like:
  0000000000000000 T MAIN__

On 08/25/2009 03:16 PM, Tim Prince wrote:
>>> function `main':
>>> (.text+0x27): undefined reference to `MAIN__'   
>>
>> I think the most likely reason is that you do not include the file
>> containing the Fortran main program (the file containing "PROGRAM").
>>
> /usr/lib/gcc/i586-redhat-linux/4.4.0/libgfortranbegin.a(fmain.o): In
> Isn't the explicit renaming of MAIN__ suspicious?
>

No, that looks OK.

What happens in gfortran up to version 4.4.x (and in ifort) is that the
Fortran main PROGRAM gets the assembler name (i.e. the name in the
assembler [*.s]/object [*.o] file) "MAIN__". The actual main function
(i.e. the one which the run-time loader calls) is called "main" and is
in an extra file which included at link time. For gfortran it is the
file "libgfortranbegin.a" (and for ifort it is "for_main.o").

Thus if the file containing the main PROGRAM is missing, the "main" is
picked up from the .a/.o file but the referenced "MAIN__" is missing.

In gfortran 4.5.x (and sunf95) the "main" function is generated along
"MAIN__". "MAIN__" still contains the actual Fortran PROGRAM while
"main" contains some initialization. Thus when linking by calling
gfortran 4.5, the error message would contain "main" rather than "MAIN__".

(Advantage of the gfortran 4.5 way: One can simply link without thinking
about whether one should like "libgfortranbegin" or not - and linking
with gfortran a project which contains a non-Fortran "main" works
better. [ifort offers the -nofor-main option but that's also not elegant.])

Tobias

PS: Regarding mixing Fortran and C - especially if the "main" program is
written in C: Have a look in the manual at
http://gcc.gnu.org/onlinedocs/gfortran/Mixed_002dLanguage-Programming.html