I used to have icpc 13.x running on Mac OS X with a copy of GCC 4.7.1 which I compiled manually from source residing in ~/gcc-4.7.1. When I call icpc -gcc-name=gcc-4.7.1 -gxx-name=g++-4.7.1 -std=c++11 it correctly sets up the compilation environment and finds all the standard c++ include headers without problem.
I've recently upgraded to Mavericks (OS X 10.9) and icpc starts spewing random linkage error so I decided to upgrade to 14.x (2013 SP1 Update 1). This works fine one I figured out that I needed to also include "-no-use-clang-env".
Next, I tried to also upgrade my GCC. This time I used Homebrew to build a copy of GCC 4.8.2 residing in its standard location in /usr/local/. However, if I now run icpc -gcc-name=gcc-4.8 -gxx-name=g++-4.8 it complains:
icpc: error #10001: could not find directory in which the set of libstdc++ include files resides
Since everything still works well if I switch back to 4.7.1 this isn't too much of a problem at the moment, but I cannot figure out why ICC is failing to find libstdc++ with my new GCC installation. (A quick look at the output of "cpp-4.8 -x c++ -v" seems to suggest that the new GCC has its own internal search paths set up correctly. Since I was under the impression that the Intel Compiler uses this to set up its own lookup paths, I am rather baffled...)
The PATH variable contains the locations for all of:
- XCode's LLVM (/usr/bin)
- My previous GCC 4.7.1 installation (~/gcc-4.7.1/bin)
- My new Homebrew-assisted GCC 4.8.2 installation (/usr/local/bin)
All of these executables have different names (gcc vs gcc-4.7.1 vs gcc-4.8, and the corresponding suffices for g++).
As I said earlier, passing "-gcc-name=gcc-4.7.1 -gxx-name=g++-4.7.1" causes icpc to correctly use my non-standard installation of GCC 4.7.1 and successfully compiles C++11 code. However, passing "-gcc-name=gcc-4.8 -gxx-name=g++-4.8" causes it to complain about missing libstdc++.