One aspect of using the Intel compilers to create Native applications or Hetergeneous Offload application is cross-compilation. When you compile for either programming model, the Intel compiler driver will call an Intel compiler on the Xeon host that creates either Phi objects, libraries, or executables. This is what is known as a "cross-compiler" - a compiler running on one host and architecture (Xeon) that creates binaries for a second architecture (Phi).
Cross compilation is no issue in and of itself. However, many complex library and application packages include complex 'configure' steps or custom build steps that may encounter problems because of this cross-compilation aspect of compiling for Phi. Some configure or build systems will attempt to compile and run a test program to help them determine things like data sizes, compiler language support, etc. Since the actual compilation host is NOT a Phi, the compiled test program will obviously fail to run (since the compiling host is Xeon and the generated binary for the test program is for Phi). This can cause the configure or build system to either make bad assumptions or outright abort.
Since many of these build systems are so complex and convoluted, it is not realistic to expect to find a workaround or fix for the build system to make it accept a cross compiler and 'do the right thing'. So what to do? We do not have a complete solution for this at this time. However an inventive user has found a clever method that may work for you:
this article discusses the problem and presents one potential work around. We will document other solutions when and if they become available.
It is essential that you read this guide from start to finish using the built-in hyperlinks to guide you along a path to a successful port and tuning of your application(s) on Intel® Xeon Phi™ coprocessors. The paths provided in this guide reflect the steps necessary to get best possible application performance.
Back to the chapter "Native and Offload Programming Models"