Avoiding g77

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding g77

Rik-4
11/25/14

Guys,

I think the best solution may be an explicit check for g77 and issuing an
error message if it is selected.

I was concerned about the brittleness of the sed solution, and accidentally
found that it is not robust.  The prologue which replaces g77 with gfortran
is run at the end of the bootstrap sequence.  However, if the time stamp on
configure.ac is modified, then the existing Makefiles take care of
re-running aclocal, automake, and autoconf.  They do not run any bootstrap
epilogue so the effect is to re-instate the default AC_PROG_F77 macro from
autoconf which has g77 listed first.  If you are a developer, adjusting the
time stamp can happen whenever you do an 'hg update' where there has been a
change in configure.ac.  This is important because 'make dist' packages up
the configure script that it finds into the tarball.  If one isn't aware of
this oddity then the wrong configure script can be exported to everyone.  I
checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and they,
at least, are clean.

To test:
sudo ln -s /usr/bin/gfortran /usr/bin/g77     # Fake having g77
make maintainer-clean
./bootstrap
cp configure configure.first   #  In case you want to see how the original
differs from the new one
./configure --options |& tee first.config.log
touch configure.ac
make |& tee make.log    # Use Ctrl+C after autoconf has finished running so
you don't need to wait for all of Octave to build
open configure with your favorite text editor and search for AC_PROG_F77

----- Results ------
## the F77 variable, if set, overrides AC_PROG_F77 automatically
ac_ext=f
ac_compile='$F77 -c $FFLAGS conftest.$ac_ext >&5'
ac_link='$F77 -o conftest$ac_exeext $FFLAGS $LDFLAGS conftest.$ac_ext $LIBS
>&5'
ac_compiler_gnu=$ac_cv_f77_compiler_gnu
if test -n "$ac_tool_prefix"; then
  for ac_prog in g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
pgf90 pghpf epcf90 gfortran g95 xlf95 f95 fort ifort ifc efc pgfortran
pgf95 lf95 ftn
---------------
g77 is listed first again.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding g77

Mike Miller
On Tue, Nov 25, 2014 at 23:08:41 -0800, Rik wrote:
> I think the best solution may be an explicit check for g77 and issuing an
> error message if it is selected.

How about a version check instead? The g77 program only exists for gcc
< 4. Add a check for GFORTRAN_VERSION, and if it is a GNU compiler and
the version is less than 4, issue an error? That seems more robust
than checking for the name being g77.

> I was concerned about the brittleness of the sed solution, and accidentally
> found that it is not robust.  The prologue which replaces g77 with gfortran
> is run at the end of the bootstrap sequence.  However, if the time stamp on
> configure.ac is modified, then the existing Makefiles take care of
> re-running aclocal, automake, and autoconf.  They do not run any bootstrap
> epilogue so the effect is to re-instate the default AC_PROG_F77 macro from
> autoconf which has g77 listed first.  If you are a developer, adjusting the
> time stamp can happen whenever you do an 'hg update' where there has been a
> change in configure.ac.  This is important because 'make dist' packages up
> the configure script that it finds into the tarball.  If one isn't aware of
> this oddity then the wrong configure script can be exported to everyone.  I
> checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and they,
> at least, are clean.

Agreed, that could happen. So are you proposing to delete
bootstrap_epilogue, and we say that an error check at configure-time
for g77 (or less than version 4) is enough to avoid the original
problem this was meant to solve? That sounds like a decent compromise
to me, especially now that systems with g77 are increasingly rare.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding g77

Daniel Sebald
On 11/26/2014 10:03 AM, Mike Miller wrote:

> On Tue, Nov 25, 2014 at 23:08:41 -0800, Rik wrote:
>> I think the best solution may be an explicit check for g77 and issuing an
>> error message if it is selected.
>
> How about a version check instead? The g77 program only exists for gcc
> <  4. Add a check for GFORTRAN_VERSION, and if it is a GNU compiler and
> the version is less than 4, issue an error? That seems more robust
> than checking for the name being g77.
>
>> I was concerned about the brittleness of the sed solution, and accidentally
>> found that it is not robust.  The prologue which replaces g77 with gfortran
>> is run at the end of the bootstrap sequence.  However, if the time stamp on
>> configure.ac is modified, then the existing Makefiles take care of
>> re-running aclocal, automake, and autoconf.  They do not run any bootstrap
>> epilogue so the effect is to re-instate the default AC_PROG_F77 macro from
>> autoconf which has g77 listed first.  If you are a developer, adjusting the
>> time stamp can happen whenever you do an 'hg update' where there has been a
>> change in configure.ac.  This is important because 'make dist' packages up
>> the configure script that it finds into the tarball.  If one isn't aware of
>> this oddity then the wrong configure script can be exported to everyone.  I
>> checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and they,
>> at least, are clean.
>
> Agreed, that could happen. So are you proposing to delete
> bootstrap_epilogue, and we say that an error check at configure-time
> for g77 (or less than version 4) is enough to avoid the original
> problem this was meant to solve? That sounds like a decent compromise
> to me, especially now that systems with g77 are increasingly rare.

I'm fine with the change as well.  The use of the epilogue isn't such a
problem, as much as the sed modifying and overwriting the file "configure".

One small variation on Rik's solution is the following:  If gfortran is
our preferred compiler, we could first check for gfortran above all
others using legal AC syntax, i.e.,

AC_PROG_F77([gfortran])
if F77 is not defined
   AC_PROG_F77
   if F77 is g77
     error message "g77 is not supported, please choose another FORTRAN
77 compiler via environment variable F77
   fi
fi

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding g77

John W. Eaton
Administrator
On 11/26/2014 11:41 AM, Daniel J Sebald wrote:

> On 11/26/2014 10:03 AM, Mike Miller wrote:
>> On Tue, Nov 25, 2014 at 23:08:41 -0800, Rik wrote:
>>> I think the best solution may be an explicit check for g77 and
>>> issuing an
>>> error message if it is selected.
>>
>> How about a version check instead? The g77 program only exists for gcc
>> <  4. Add a check for GFORTRAN_VERSION, and if it is a GNU compiler and
>> the version is less than 4, issue an error? That seems more robust
>> than checking for the name being g77.
>>
>>> I was concerned about the brittleness of the sed solution, and
>>> accidentally
>>> found that it is not robust.  The prologue which replaces g77 with
>>> gfortran
>>> is run at the end of the bootstrap sequence.  However, if the time
>>> stamp on
>>> configure.ac is modified, then the existing Makefiles take care of
>>> re-running aclocal, automake, and autoconf.  They do not run any
>>> bootstrap
>>> epilogue so the effect is to re-instate the default AC_PROG_F77 macro
>>> from
>>> autoconf which has g77 listed first.  If you are a developer,
>>> adjusting the
>>> time stamp can happen whenever you do an 'hg update' where there has
>>> been a
>>> change in configure.ac.  This is important because 'make dist'
>>> packages up
>>> the configure script that it finds into the tarball.  If one isn't
>>> aware of
>>> this oddity then the wrong configure script can be exported to
>>> everyone.  I
>>> checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and
>>> they,
>>> at least, are clean.
>>
>> Agreed, that could happen. So are you proposing to delete
>> bootstrap_epilogue, and we say that an error check at configure-time
>> for g77 (or less than version 4) is enough to avoid the original
>> problem this was meant to solve? That sounds like a decent compromise
>> to me, especially now that systems with g77 are increasingly rare.
>
> I'm fine with the change as well.  The use of the epilogue isn't such a
> problem, as much as the sed modifying and overwriting the file "configure".
>
> One small variation on Rik's solution is the following:  If gfortran is
> our preferred compiler, we could first check for gfortran above all
> others using legal AC syntax, i.e.,
>
> AC_PROG_F77([gfortran])
> if F77 is not defined
>    AC_PROG_F77
>    if F77 is g77
>      error message "g77 is not supported, please choose another FORTRAN
> 77 compiler via environment variable F77
>    fi
> fi

This seems like a reasonable solution to me.  I'm not as concerned about
g77 being installed with some other name, but if there is a way to
identify g77 without just looking at the name of the program that would
be fine with me too.

I agree that the problem I was trying to solve is probably not much of a
problem now, though it certainly was for a while, when people had old
versions of g77 installed that were incompatible with their version of GCC.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Avoiding g77

Rik-4
On 11/26/2014 09:06 AM, John W. Eaton wrote:

> On 11/26/2014 11:41 AM, Daniel J Sebald wrote:
>> On 11/26/2014 10:03 AM, Mike Miller wrote:
>>> On Tue, Nov 25, 2014 at 23:08:41 -0800, Rik wrote:
>>>> I think the best solution may be an explicit check for g77 and
>>>> issuing an
>>>> error message if it is selected.
>>>
>>> How about a version check instead? The g77 program only exists for gcc
>>> <  4. Add a check for GFORTRAN_VERSION, and if it is a GNU compiler and
>>> the version is less than 4, issue an error? That seems more robust
>>> than checking for the name being g77.
>>>
>>>> I was concerned about the brittleness of the sed solution, and
>>>> accidentally
>>>> found that it is not robust.  The prologue which replaces g77 with
>>>> gfortran
>>>> is run at the end of the bootstrap sequence.  However, if the time
>>>> stamp on
>>>> configure.ac is modified, then the existing Makefiles take care of
>>>> re-running aclocal, automake, and autoconf.  They do not run any
>>>> bootstrap
>>>> epilogue so the effect is to re-instate the default AC_PROG_F77 macro
>>>> from
>>>> autoconf which has g77 listed first.  If you are a developer,
>>>> adjusting the
>>>> time stamp can happen whenever you do an 'hg update' where there has
>>>> been a
>>>> change in configure.ac.  This is important because 'make dist'
>>>> packages up
>>>> the configure script that it finds into the tarball.  If one isn't
>>>> aware of
>>>> this oddity then the wrong configure script can be exported to
>>>> everyone.  I
>>>> checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and
>>>> they,
>>>> at least, are clean.
>>>
>>> Agreed, that could happen. So are you proposing to delete
>>> bootstrap_epilogue, and we say that an error check at configure-time
>>> for g77 (or less than version 4) is enough to avoid the original
>>> problem this was meant to solve? That sounds like a decent compromise
>>> to me, especially now that systems with g77 are increasingly rare.
>>
>> I'm fine with the change as well.  The use of the epilogue isn't such a
>> problem, as much as the sed modifying and overwriting the file "configure".
>>
>> One small variation on Rik's solution is the following:  If gfortran is
>> our preferred compiler, we could first check for gfortran above all
>> others using legal AC syntax, i.e.,
>>
>> AC_PROG_F77([gfortran])
>> if F77 is not defined
>>    AC_PROG_F77
>>    if F77 is g77
>>      error message "g77 is not supported, please choose another FORTRAN
>> 77 compiler via environment variable F77
>>    fi
>> fi
>
> This seems like a reasonable solution to me.  I'm not as concerned about
> g77 being installed with some other name, but if there is a way to
> identify g77 without just looking at the name of the program that would
> be fine with me too.
>
> I agree that the problem I was trying to solve is probably not much of a
> problem now, though it certainly was for a while, when people had old
> versions of g77 installed that were incompatible with their version of GCC.
>

I think this is mostly a non-issue now.  g77 was back in the 3.X series of
gcc and recent new version tests in Octave's configure.ac require at least
version 4.1.  I have checked in a change that removes the
bootstrap_epilogue and makes gfortran the preferred compiler.  The autoconf
code is now

## Prefer gfortran, but the user's F77 environment variable will override.
AC_PROG_F77([gfortran])
if test -z "$F77"; then
  ## No gfortran found, search for any other installed compiler.
  AC_PROG_F77
fi
if test "$F77" = g77; then
  AC_MSG_ERROR([g77 is not a supported Fortran compiler.  Select another
compiler by setting the environment variable F77 and re-running configure.])
fi

--Rik