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).