Re: infer GCC_REQD from USE_LANGUAGES

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> Mixing GCC versions doesn't work well.
Yes. Therefore, that's exactly what my proposes solution/patch avoids.

To repeat my proposal:
1. Choose /the one single GCC version/ to build everything with (besides 
   that GCC itself, of course. Provide defaults for OS/version combinations, 
   let user override (once for the whole build).
2. Infer (additional) GCC_REQD values from USE_LANGUAGES.
3. Error out in case GCC_REQD sums up to a higher GCC that what was chosen.
4. Build with the GCC version chosen.

Open questions:
1. Building GCC may build libraries with a lower GCC than the rest.
   Can we re-use them or do we need to build them into another PREFIX?
2. The base GCC version may be unable to build the target GCC, we may need to
   build an intermediate version. This may build dependencies we need to 
   discard/put into an interim PREFIX.

Open details:
1. Does it work to use a lower GCC for C-only packages?
   Benefit: don't need to build GCC if not building C++ packages.
2. Which GCC version do we regard as C++nn-capable?
3. Determine exact set of (recursive) GCC dependencies (varies with OS).

The current situation is a mixture of some local works-for-me patches plus 
an attitude to ignore the problem and wait until NetBSD versions using a 
"too old" base gcc becomes unsupported an as such can be openly ignored. 
Which doesn't work well because upstreams will demand newer GCCs/C++ levels 
faster than NetBSD versions age out. Unless pkgsrc support is cut to 
NetBSD-current only, something needs to be done.