GCCROOT in Practice and ICE Adventures! :)

Hi! :)  I was getting an ICE with 2019.1, 2019.5, and 2020.1 while trying to compile OpenCV from source.  System info:

$ uname -r
5.5.17-200.fc31.x86_64

$ gcc --version
gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)

$ ldd --version
ldd (GNU libc) 2.30

$ ld --version
GNU ld version 2.32-31.fc31

My system (Fedora 31, kernel/gcc/binutils/ld pinned [fedora defaults to rolling updates]) ships with an incompatible binutils and gcc version.  Officially, it's unclear whether or not fc31 is valid (docs list it under -qnextgen, but not under main OS listings).  So I compiled `gcc@8.4.0` and `binutils@2.29.1` from source.  I was able to solve the ICE by compiling (almost) the full dependency stack via `gcc@8.4.0` and `binutils@2.29.1`.  I was then able to compile python, numpy, and then OpenCV using Intel successfully (mostly including this information to inform any potential future readers that you don't necessarily need to compile the full stack with Intel, prioritize the ones that are important to you).  To be clear, I don't think there's anything Intel can / should do on their end to resolve the ICE I ran into.  I _believe_ what happened is that even though I was requesting OpenCV not build the GUI components, the system Qt was getting dragged in (I use KDE, so I can't remove it).  At link time `mcpcom` was segfaulting, presumably because there's all these objects from both `gcc@9.3.1` and `gcc@8.4.0` flying around.  I'm happy to label that a "usage error" on my end hehe :)

However, while investigating how to solve this I tried to wield GCCROOT.  I'm working in the context of the `spack` package manager (was able to ICE building manually though), and one of the core goals of `spack` is to get the best possible build isolation we can.  While playing with GCCROOT, I'm unsure how to actually be able to use it in practice.  Consider a simple `hello_world.c`, if I load my `gcc@8.4.0` and `binutils@2.29.1` modules (or use `-gcc-name` etc):

$ icc -v hello_world.c 
icc version 19.1.1.217 (gcc version 8.4.0 compatibility)
...
#include "..." search starts here:
#include <...> search starts here:
...
/usr/local/include
/usr/include

ld
    ...
    -L/lib/../lib64
    -L/lib/../lib64/
    -L/usr/lib/../lib64
    -L/usr/lib/../lib64/
    ...
    -L/lib64
    -L/lib/
    -L/usr/lib64
    -L/usr/lib

I'm highlighting the concerning entries, it seems like my underlying issue was (1) the OpenCV build system was picking up things I didn't want it to and (2) the `/usr/*` and `/lib*` entries are problematic in my scenario.  If I export GCCROOT to the from-source `gcc@8.4.0` installation prefix, though:

$ icc -v hello_world.c 
icc version 19.1.1.217 (gcc version 8.4.0 compatibility)
...
hello_world.c(1): catastrophic error: cannot open source file "stdio.h"
  #include <stdio.h>
                    ^

compilation aborted for hello_world.c (code 4)

The `/usr/include` and `/usr/local/include` entries are not there (good!), but here's where things get really confusing to me.  After comparing the custom and system install trees, I've noticed some seemingly significant differences.  `stdio.h` is one of a number of header files that are not installed where Intel is expecting them (`syslimits.h` was another).  I've been looking at our build scripts and the GCC compilation documentation, but am unable to discern how the linux packaging gurus do whatever they do to produce the installation tree.  The removal of `/[usr]/include` and `/lib*` are quite desirable for us.  Is there any in-depth documentation or advice for how we can get a from-source build of GCC to install in the way the Intel compilers are expecting?  It seems to me that setting `GCCROOT`, `GXXROOT`, and `GCC_EXEC_PREFIX` would be the golden standard for us to get a truly isolated build via Intel's (magical) compilers :)

Thank you in advance for any suggestions / tips!  I'm rather intrigued by the differences in the install trees and how to reconcile them if we can!