FCLIBS do not contain objects required for AC_FC_MAIN to succeed

[Thomas Jahns]

Hello,

please notice that I focus on modern Fortran below, but all arguments are
equally valid for the F77 part of the macros concerned.

I encountered a bug where some Fortran compilers (ifort and nagfor to be
precise) add object files to the link and AC_FC_MAIN will not find the Fortran
name of the primary entry point because these are missing from FCLIBS.

On the other hand AC_FC_DUMMY_MAIN requires FCLIBS to not contain the Fortran
main symbol because otherwise all link tests in AC_FC_DUMMY_MAIN will fail
because of multiple definition of main.

I noticed this because of the following turn of events
1. Our projects creates a library of C and Fortran code to be used by both C and
Fortran programs
2. Initially the library was built statically only, therefore I used
AC_FC_DUMMY_MAIN and linked the C programs with the C compiler
3. Then I introduced libtool to also be able to build a shared library. Since
the library contains Fortran and C code, the shared object also depends on the
Fortran libraries (i.e. libraries for Fortran in addition to the Fortran
run-time libraries that FCLIBS contains) and I decided to change the linking of
C programs to use the Fortran compiler driver (i.e. set prog_LINK = $(FCLINK) in
Makefile.am). To facilitate this switch I needed the AC_FC_MAIN check to work
more reliably than currently I therefore hacked the _AC_FC_LIBRARY_LDFLAGS macro
to also include .o files not matching crt*.o in FCLIBS.
4. Therefore my configure.ac ended up having both: AC_FC_MAIN and
AC_FC_DUMMY_MAIN and configure runs failed for the above two compilers.

Since I feel both macros should just work[1], I propose to extend
_AC_FC_LIBRARY_LDFLAGS to build two output variables instead of one: FCLIBS as
it is now and another also containing the required object files to be used for
the tests in AC_FC_MAIN.

I'd like to contribute a corresponding patch if the above idea seems acceptable
for the autoconf maintainers but I'd also like to look into another solution if
this seems more appropriate. I'd also welcome name suggestions for the
additional output variable.

Regards,
Thomas Jahns

[1] Independent of whether it would be a better design decision to not also have
the Fortran parts in the same shared object. Separating both parts will be
something I'll look into in the future but at this time too much functionality
is Fortran-only to justify having a separate library for the benefit of a few C
test programs only.
-- 
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns <address@hidden>

smime.p7s
Description: S/MIME Cryptographic Signature