We were using icpc XE 2013 on Fedora 17 (integrated with GCC 4.7.2) as our main dev environment for some projects, utilizing C++11 features. Lately, we had to switch to RHEL 6.3 that is accompanied with GCC 4.4.2 (which does not support the C++11 features we are using), so we had to install a chrooted GCC 4.7.2, and link the icpc to it using -cxxlib=dir compiler option.
However, we get linking errors when compiling, like e.g.: undefined reference to `std::placeholders::_1' or undefined reference to `std::string::operator=(std::string&&)'. Yet, when compiling the same project using the chrooted g++ (4.7.2), it is compiled correctly.
Any idea what's going wrong here?
How did you install chrooted g++? When we talked about "chroot", I guess it is "change root" for a SYSTEM. It should have "/bin", "/usr/bin"...and so on...
If your environment is as above, using chroot to set up an environment for a "target" system, you may try the "--sysroot=dir" option of Intel Compiler.
But from my understanding of your description, your environment is not a real chroot enviroment. it seems like you install gcc to a standalone folder (maybe you build from source and install to a standalone folder), for example, you install to "/opt/gcc4.7.2". If this is your case, you may need to do as below:
(Note: /opt/gcc/prerequisite-lib/lib/lib is the folder for gcc's prerequisite libs, such as mpfr/gmp/mpc libraries, change it accordingly.)
In one word, you need to make sure GCC 4.7.2 is set up correctly before using Intel compiler, as Intel compiler depends on gcc environment.
Please let me know whether this can work.
To put it more simply, the g++ from which you want to inherit headers must be first on PATH and LD_LIBRARY_PATH. icpc will use 'g++ -print-search-dirs' to find them. Shenghong assumes that you are using icpc for Intel64 (64-bit).
It sounds like the -cxxlib=dir option is not working as expected and you are picking up the GNU version 4.7 version of the header files but you are linking with the GNU 4.4.2 version of the libcxxstd library. Does a lib or a lib64 subdirectory exist under dir? If you explicit force the GNU 4.7 libraries to be used (by using -Lnameofdirwhere4.7librariesexist) does that fix the problem?