Re: Selecting a C++ compiler

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

On 11/25/17 19:38, Greg Troxel wrote:
> I have written up some notes about this discussion.  I probably got some
> things wrong, and there are some points marked as too be resolved.
>
> https://wiki.netbsd.org/pkgsrc/gcc/
>
> The big things to think about and discuss are:
>
>    What do we do on NetBSD 7 (which has gcc 4.8).  My proposal is to use
>    gcc 6 for C++, and the base version for C.
>
>    Is it ok to set gcc-inplace-math and try to drive dependencies for
>    gcc* to near zero?  If that's ok, let's do it.  Probably anything
>    older than gcc48 isn't of interest and we don't need to mark those for
>    bootstrap.  I think gcc48 is the oldest even slightly reasonable
>    choice for a bootstrap version.
>
>    The branch is coming, but remember that things are more or less broken
>    on NetBSD 6 because of this issue.  I think Edgar has pending patches
>    that more or less do that is described.
>
> So please feel free to fix/explain what I got wrong, or send mail about
> it, to me if it's a nit, or to the list if substantive.

Disabling gcc-inplace-math did not reduce dependencies much on my CentOS 
systems.  Is it different on NetBSD?

For 2017Q3, GCC 4.8 seemed to work best on CentOS, but GCC 5 is close.  
There still appears to be a lot of work to do toward GCC 6 compatibility 
across the whole collection.  Below are counts for successful pbulk builds.

www/pkgsrc/packages/sharedapps/pkg-2017Q3/Darwin15/All    14162
14162    353904
www/pkgsrc/packages/sharedapps/pkg-2017Q3/Darwin16/All    14012
14012    350024
www/pkgsrc/packages/sharedapps/pkg-2017Q3/NetBSD-7.1/All    17986
17986    450288
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc6/All    15849
15849    399983
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6/All    16459
16459    414444
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc5/All    16338
16338    411103
www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7/All    16413
16413    413010

Maybe this should be dealt with separately, but has any thought been 
given to compatibility between gfortran and clang on platforms such as 
Darwin and FreeBSD?  FreeBSD ports has ways to deal with it, although 
they are a little messy.  Here's an example of a FreeBSD port that mixes 
boost compiled with clang++ and blas/lapack compiled with gfortran:

https://github.com/outpaddling/freebsd-ports-wip/tree/master/bolt-lmm

The logic for dealing with compiler and library issues is here, much of 
it in Uses/compiler.mk:

https://github.com/freebsd/freebsd-ports/tree/master/Mk

I'm inclined to save this for another day, but it might have some 
bearing on the choice of a default GCC compiler if we're planning ahead 
for that day.  I.e. which of gcc48, gcc5, or gcc6 is most compatible 
with the base clang on a given platform?  Or maybe punt on this and 
focus on integrating flang for those platforms when that's feasible?

--
Earth is a beta site.