Re: Can we make gfortran the default Fortran?

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Dec 31, 2017 at 11:25:30AM -0600, Jason Bacon wrote:
 > 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."

AIUI:

 - the package says USE_LANGUAGES+=c++03
 - the package says GCC_REQD=4.8

The minimum gcc version for c++03 is (I forget, but let's pretend it's
4.2); combining this with 4.8 makes 4.8 the minimum required version.

If PKGSRC_GXX_VERSION is 4.7, meaning the gcc version we're using for
C++ is 4.7, the build will abort, because we're using 4.7 but the
package needs 4.8. If PKGSRC_GXX_VERSION is 5.0, the build won't fail
and we'll compile with 5.0.

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

and

> Correction: Tagging packages individually would ensure consistent builds,
 > not the recursive PKGSRC_GCC_BOOTSTRAP variable.? My thoughts got jumbled
 > here.? For example, with the recursive variable, bzip2 could be built with
 > the system compiler or pkgsrc compiler depending on what build depends on
 > it.? Tagging bzip2 explicitly would ensure that it's always built with the
 > system compiler, if I'm understanding the proposal correctly.

Yes.

There's another issue though: sometimes it's ok to have a few packages
built with a different compiler, assuming they work; for example, on
NetBSD-6 where there's nothing particularly wrong with the system
compiler other than it changing slower than the C++ standard. There
are other times though when you would rather avoid the bootstrap
compiler as much as possible, e.g. if you had to compile it
specifically too and it's just wasting disk space by sitting around,
or if it's a pile, or if the stuff built with it doesn't actually
interoperate with stuff built with the real compiler.

I think it would be good to make sure this scenario works. It can
certainly be handled by bootstrapping multiple pkgsrc trees, but
that's messy and hopefully there's an easier way.

Also I have a feeling that on various vintage platforms bootstrapping
to gcc5 will require multiple stages...

-- 
David A. Holland
dholland%netbsd.org@localhost