|Subject:||Re: Default F77 is g77|
|Date:||Mon, 24 Nov 2014 14:27:10 -0800|
On 11/24/2014 02:00 PM, John W. Eaton wrote:|
> On 11/24/2014 04:54 PM, Rik wrote:
>> Interestingly, this is the entire list of known compilers so we could
>> simply put this list in as the preference to AC_PROG_F77 with gfortran at
>> the start like so:
>> AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
>> pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn])
>> I did this and it now picks up gfortran even with g77 symlinked in /usr/bin.
> I don't like this solution for the reasons that Mike Miller already stated.
> Also, leaving g77 in the list has the problem of screwing things up if a system happens to have an old copy of g77 installed but no gfortran. As far as I know, there are no versions of g77 that will work with modern versions of gcc and g++. Since we rely on linking Fortran and C++ code together, we must have a consistent set of compilers and g77 will never work properly for us. So we might as well simply avoid it by replacing instances of g77 in the configure script with gfortran. That solution seems to be working for us, so I don't see a reason to change it.
I understand not fixing what isn't broken, but there is also futureproofing. Using sed on the generated configure feels like a fragile solution that may break as things change in the future. I think putting in the full list of compilers is also a hack, just slightly less fragile, as I don't see many new Fortran compilers being written.
Another alternative I like is to error out with a message about the problems with g77 if it is selected, rather than substituting gfortran without the user's permission. In pseudocode,
if "$F77" = g77; then
AC_MSG_ERROR([Detected Fortran compiler g77 which does not produce objects that can be linked with BLAS and LAPACK libraries. Choose a different compiler by setting the environment variable F77 and re-running configure.]
|[Prev in Thread]||Current Thread||[Next in Thread]|