This is the mail archive of the
mailing list for the GNU Fortran project.
Re: undefined reference to `MAIN__'
- From: Tobias Burnus <burnus at net-b dot de>
- To: chao sun <1988sunchao at gmail dot com>
- Cc: fortran at gcc dot gnu dot org
- Date: Tue, 25 Aug 2009 16:56:07 +0200
- Subject: Re: undefined reference to `MAIN__'
- References: <email@example.com> <firstname.lastname@example.org> <4A9386D6.email@example.com> <firstname.lastname@example.org>
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.])
PS: Regarding mixing Fortran and C - especially if the "main" program is
written in C: Have a look in the manual at