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 <jahns@xxxxxxx>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
