Re: Can we make gfortran the default Fortran?

[Jason Bacon <bacon4000%gmail.com@localhost>]

On 12/29/17 19:59, Greg Troxel wrote:
> can you check what I said you said in the gcc wiki page?  Basically 5 is
> the right answer for now

Doing a thorough review of the wiki now, here are some key points:

1. Yes, I think gcc5 is the best option at this time.

Here are the actual counts again.

www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc6/All    15849
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc48/All    16461

www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc5/All    16338
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc48/All    16414

2. Avoiding a gcc package build is of no value to the scientific 
computing community, as it will happen very soon anyway when the need 
for a C++ or Fortran dependency comes into play (e.g. boost, blas).

It may be of value to others with very different use cases, though.

If we implement PKGSRC_GCC_VERSION and PKGSRC_GXX_VERSION separately as 
suggested, this decision is handed down to the end user in a 
satisfactory way.  PKGSRC_GFORTRAN_VERSION will be important to 
scientific computing as well.

I've been using PKGSRC_FORTRAN=gfortran for years on CentOS 6 and 7 and 
it has been very stable.

So my approach on Linux will be to require gcc5 for all three languages 
for now and move to gcc6 when bleeding-edge issues subside.

3. I'm unclear about the meaning of "The minimum version inferred from 
the language tag will be combined with any GCC_REQD declarations to find 
a minimum version for a specific package. If that is greater than 
PKGSRC_GCC_VERSION (programs using only C) or PKGSRC_GXX_VERSION, 
package building will fail."

4. Can someone provide a specific example of how the 
PKGSRC_GCC_BOOTSTRAP=yes might cause a problem?  I think building 
dependencies with the system compiler and linking against them with a 
newer pkgsrc compiler should be fine in almost all cases, and a 
recursive PKGSRC_GCC_BOOTSTRAP variable should ensure consistency in gcc 
and dependency builds (unless I'm overlooking something).

5. Making this work on clang-based Darwin will be of interest as well, 
but I wouldn't let that interfere with resolving immediate issues on 
NetBSD and RHEL/CentOS.

Thanks,

    Jason

--
Earth is a beta site.