--- wikisrc/pkgsrc/gcc.mdwn	2017/11/26 01:07:36	1.1
+++ wikisrc/pkgsrc/gcc.mdwn	2017/11/26 01:20:23	1.2
@@ -1,8 +1,6 @@
-Using gcc in pkgsrc
-
 On many systems pkgsrc supports, gcc is the standard compiler.  In
 general, different versions of each OS have different gcc versions,
-and some packages require newer GCC versions, in order to support
+and some packages require newer gcc versions, in order to support
 newer language standards (e.g. c++11, written in the style of
 USE_LANGUAGES), or because older versions don't work (infrequently).
 
@@ -45,33 +43,42 @@ This section attempts to gather all the 
   - The set of packages that are needed when building a bootstrap
     compiler should be minimized.
 
-  - All packages that use C++ should be built with the same compiler version.
-
   - All packages that use C should have final linking with the highest
     version used in any included library.
 
+  - All packages that use C++ should be built with the same compiler
+    version.  Because these typically also include C, the version used
+    for C++ must be at least as new as the version used for any used C
+    package.
+
   - pkgsrc should avoid building gcc unless it is more or less
     necessary to build packges.  (As an example, if the base system
     gcc can build c99 but not c++11, building a c99-only program
     should not trigger building a gcc version adequate for c++11.)
 
-  - The compiler selection logic should work on NetBSD 6, and in-use
-    (including LTS) GNU/Linux systems.  It is desirable for this logic
-    to work on NetBSD 5.
+  - The compiler selection logic should work on NetBSD 6 and newer,
+    and other systems currently supported by pkgsrc, including in-use
+    LTS GNU/Linux systems.  It should work on systems that default to
+    clang, when set to use GCC, at least as well as the current
+    scheme.  It is desirable for this logic to work on NetBSD 5.
 
   - The compiler selection logic should be understandable and not brittle.
 
 ## Design
 
 The above requirements could in theory be satisfied in many ways, but
-most of them are too complicated.
+most of them are too complicated.  We present a design that aims to be
+sound while mimimizing complexity.
 
   - Packages declare what languages they need, with c++, c++11, and
-    c++14 being expressed differently.
+    c++14 being expressed differently.  (This is exactly current
+    practice and just noted for completeness.)
 
   - The package-settable variable GCC_REQD will be used only when a
     compiler that generally can compile the declared language version
-    is insufficient.  These cases are expected to be relatively rare.
+    is insufficient.  These cases are expected to be relatively rare;
+    an example is firefox that is in c++ (but not c+11) and needs gcc
+    4.9.
 
   - A user-settable variable PKGSRC_GCC_VERSION will declare the
     version of gcc to be used for C programs, with an OS- and
@@ -121,6 +128,9 @@ most of them are too complicated.
     approach is possible inconsistency with gcc's dependencies being
     built with the base compiler and used later.
 
+  - We hope that the chosen version can be built using the base system
+    version, and hope to avoid multi-stage bootstrapping.
+
   - We expect that any program containing C++ will undergo final
     linking with a C++ compiler.  This is not a change from the
     current situation.
@@ -157,8 +167,7 @@ not used.  \todo Discuss.
 
 When the base system is almost new enough, the decision about the
 default is more complicated.  A key example is gcc 4.8, found in
-NetBSD 7.  Firefox requires gcc 4.9 (\todo because the c++11 support
-in 4.8 is not quite good enough), and all programs using c++14 also
+NetBSD 7.  Firefox requires gcc 4.9, and all programs using c++14 also
 need a newer version.  One options is to choose 4.8, resulting in
 firefox failing, as well as all c++14 programs.  Another is to choose
 4.9, but this makes little sense because c++14 programs will still
@@ -173,6 +182,18 @@ used.  By "new enough", we mean that alm
 to build with it, which implies that it supports (almost all) C++14
 programs.   Our current definiton of new enough is gcc 5.
 
+### Limited mixed versions
+
+One approach would be to allow limited mixed versions, where
+individual programs could force a specific version to be bootstrapped
+and used, so that e.g. firefox could use 4.9 even though most programs
+use 4.8, which is what happens now on NetBSD 7.  This would rely on
+being able to link c++ with 4.9 including some things built with 4.8
+(which is done presently).  However, this approach would become
+unsound with a library rather than an end program.  We reject this as
+too much complexity for avoiding building a newer compiler in limited
+situations.
+
 ### Fortran
 
 Fortran support is currently somewhat troubled..  It seems obvious to