topic > I'm guessing this would be in Software Archive

Problem building for MIC as build process needs to execute binaries

Fiona_R_ — Thu, 02 May 2013 15:05:00 GMT

Hi Folks,

I'm currently trying to build the version 1.1.4 of the libint library (the code can be found at http://sourceforge.net/projects/libint/files/v1-releases/libint-1.1.4.tar.gz/download) for use with the CP2K code on the MIC.

My configure line is as follows:

./configure CXX=icpc CC=icc FC=ifort FFLAGS="-O3 -mmic" --with-cc-optflags="-O3 -mmic" --with-cxx-optflags="-O3 -mmic" --with-libdirs="-O3 -mmic" --prefix=/users/fiona/lib/libint-intel-mic --host=x86_64-unknown-linux-gnu

The --host flag ensures cross compilation, otherwise configure will fail when it attempts to execute a binary compiled for the MIC on the host.

The build (make) process for libint 1.1.4 executes a number of binaries however as these are compiled up for the MIC cards my build fails as the host can't execute the MIC binary.

My MIC cards don't have any compilers available on them thus compiling everything on the MIC isn't an option.

Any suggestions for how to get round this problem would be brilliant. It must be something other MIC users have encountered as quite a number of codes and libraries execute binaries as part of their build process.

Many thanks,

Fiona

Hi Folks,

Fiona_R_ — Thu, 02 May 2013 16:17:19 GMT

Hi Folks,

Apologies, I've now found a solution, basically, do the majority of the build on the host and when the build fails execute the 3 binaries: build_libint, build_libr12 and build_libderiv on the MIC and resume the build on the host. It's rather clunky, but as I need the libraries to be optimised for the MIC it looks like there's no other option here.

Cheers,

Fiona

The nomenclature is confusing

DubitoCogito — Thu, 02 May 2013 17:11:36 GMT

The nomenclature is confusing, but --host should not be set to the build system. x86_64-unknown-linux-gnu is a generic description for a standard x86-64 system running Linux. I have had success using --host=blackfin which works because it does not match the build system description and so configure does not try to run code because it knows the code is being cross-compiled.

Using --host=blackfin gives

Fiona_R_ — Fri, 03 May 2013 08:14:32 GMT

Using --host=blackfin gives the following error as there's no blackfin target in configure etc:

checking build system type... x86_64-unknown-linux-gnu
checking host system type... Invalid configuration `blackfin': machine `blackfin' not recognized
configure: error: /bin/sh bin/config.sub blackfin failed

I used --host=blackfin to build fftw3.3.3 but I don't think that wil work for libint-1.1.4. Running the make on the host (where I have compilers available) and then executing the 3 binaries on the MIC seems to give me a MIC compatible library.

Fiona

Thanks Olli,

Fiona_R_ — Thu, 09 May 2013 13:59:25 GMT

Thanks Olli,

Unless I'm missing something obvious I don't see any micrun.txt attachment?

I'm guessing this would be something the sysadmins would need to install for me? I don't have root access!

Best regards,

Fiona

> I'm guessing this would be

James_C_Intel2 — Wed, 15 May 2013 09:34:49 GMT

> I'm guessing this would be something the sysadmins would need to install for me?

Yes, you would need your sysadmin to do this on the host processor.

Hi Fiona!

Olli-Pekka_L_ — Wed, 22 May 2013 07:35:34 GMT

Hi Fiona!

There's a small trick you can do with the binfmt_misc kernel feature. You can use it to automatically launch K1OM (MIC) binaries on the MIC side when you try to execute them on the host. We call this "Execution auto-offloading". Basically you need 2 things.

A configuration string fed to /proc/sys/fs/binfmt_misc/register directing binaries with a specific binary fingerprint to be executed via a handler program or script (The filename of the binary is passed as an argument to this program or script).
A handler program or script which takes the filename as the argument and executes the program on the MIC side (passing also relevant environment variables and the return value).

Here is the command to configure binfmt_misc to use a script called /usr/bin/micrun as the handler script for MIC binaries.

echo ':K1OM:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb5:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff:/usr/bin/micrun:' > /proc/sys/fs/binfmt_misc/register

This setting will be cleared on reboot but you can make it persistent by putting it into an init file (i.e. /etc/init.d/rc.local on RHEL -based systems).

I have attached our /usr/bin/micrun handler script (had to rename it to 'micrun.txt' to be able to attach it). It passes also MIC_* environment variables correctly and returns the return values. It assumes that the working directory on the MIC side is identical to the host-side (e.g. NFS mounted /home).

Sorry if the explanation is a bit obtuse but I'm planning to make a blog post about this where it will hopefully be a bit clearer.

Thanks to Jim Cownie of Intel for pointing out the binfmt_misc capability. We used to do it in a clunkier way with LD_PRELOAD but this is much better.

Quote:Fiona R. wrote:

Olli-Pekka_L_ — Wed, 22 May 2013 07:47:26 GMT

Fiona R. wrote:

Thanks Olli,

Unless I'm missing something obvious I don't see any micrun.txt attachment?

I'm guessing this would be something the sysadmins would need to install for me? I don't have root access!

Best regards,

Fiona

Sorry about that. I have now attached the script. As Jim mentioned, root access is needed.