Topic brought up on #gfortran by Janne. There are some potential issues in using main.c in a library; thus one should have only link a "main()" if the *.o files don't have a "main".
See also: http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/e35b2224a7dc27bf/ http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7d483c59db0bb6f/ The solution of SUN is to generate for PROGRAM not only a "MAIN_" but also a main() which does the initialization and calls then MAIN_. ("MAIN_" should be present for backward compatibility.) I think we could do likewise, especially as the code is rather short (libgfortran/fmain.c): main (int argc, char *argv[]) { store_exe_path (argv[0]); set_args (argc, argv); MAIN__ (); /* The Fortran PROGRAM */ return 0; } Intel's solution is to link "for_main-o", but that is not as elegant as for "ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C library. * * * Independent of all, I think one should document the gfortran_init() functions to make the full library functions available even if the "main()" program is written in C. Besides store_exe_path (argv[0]); set_args (argc, argv); (which should be combined to one function) one also has _gfortran_set_options() * * * Marked as depending on the array descriptor stuff as with the ABI break one can get also rid of fmain.c's main(). It might also help with -fwhole-program (cf. PR fortran/26682) as a "main()" shouldn't be optimized away ;-) -- Summary: Generate main() rather than using a main in libgfortran/fmain.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 36825 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
