GCCROOT in Practice and ICE Adventures! :)

[smcdo5]

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!

[AbhishekD_Intel]

Hi Stephen,

Please try specifying the location of the header file at a time of compiling like icc -I/<path to include dir where stdio.h is present> hello_world.c and check if it works or not. Otherwise, try completely uninstalling and then reinstalling it. And if possible try fixing your /usr and /lib directories because all the applications will first search headers from the default path.

If after trying above your issue is not resolved then please give us detailed steps that you took to encounter your issue, so that we can reproduce it at our end.

Warm Regards,

Abhishek 

[smcdo5]

Hi Abhishek,

Thanks for the response.  It seems to be more a matter of GCCROOT expects a special kind of layout then a "normal GCC built from source" (big quotes on that), I think this has to do with the sysroot configuration flags for GCC.  I plan to do some more investigation / try and replicate this on another machine and/or docker image since I agree ... the information I have given you is not helpful in terms of reproducing :D  I was hopeful maybe I was overlooking some kind of common knowledge surrounding GCCROOT but it appears to be a more involved scenario.

Have a great weekend, I hope to report back soon with more useful information!

-Stephen

[AbhishekD_Intel]

Hi,

Please give us an update if you have reproduced the problem. You can also confirm whether we can close this thread or not.

Thank you

[AbhishekD_Intel]

Hi,

Please give us an update on your reproducer.

Thank you

[AbhishekD_Intel]

Hi,

For now, we are closing this thread please post back to us whenever you will reproduce the issue.

Thank you.