[LU-2752] Enhance build for cross compilation for the Intel(R) Xeon Phi(TM) card

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.4.0
• Type: Improvement
• Priority: Minor
• Reporter: Dmitry Eremin (Inactive)
• Assignee: Dmitry Eremin (Inactive)
• Resolution: Fixed

Description

Current Lustre build is not support cross compilation for the
Intel(R) Xeon Phi(TM) card. So, producing binaries
for MIC card is not trivial now and required manual changes of
sources. It would be very beneficial to provide an easy way to
produce client binaries for the Intel(R) Xeon Phi(TM) card
directly from GIT repository just specifying appropriate
--host and --build option for ./configure script.

For example, to produce Lustre binaries for MIC card just execute
the following:

./configure --host=x86_64-k1om-linux --build=x86_64-pc-linux

Comments

[Robert Read (Inactive)]

When cross compiling, --host is system on which you are doing the compilation, and --target is the system that you building binaries for. So you need to do something like this:

./configure --host=x86_64-pc-linux --target=x86_64-k1om-linux

[Alex Zhuravlev]

usually configure is capable to recognize build system. e.g., i'm building on os/x to run in regular linux env with the following:
configure --host=x86_64-unknown-linux

where:
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

[Alex Zhuravlev]

$ luconfig --with-linux=/work/linux-2.6.32-279.2.1 --disable-liblustre --with-spl=/work/lustre/spl --with-spl-obj=/work/lustre/spl --with-zfs=/work/lustre/zfs --with-zfs-obj=/work/lustre/zfs
checking build system type... x86_64-apple-darwin12.2.1
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
...

[Dmitry Eremin (Inactive)]

I used description from http://www.gnu.org/software/autoconf/manual/automake.html

2.2.8 Cross-Compilation

To cross-compile is to build on one platform a binary that will run on another platform. When speaking of cross-compilation, it is important to distinguish between the build platform on which the compilation is performed, and the host platform on which the resulting executable is expected to run. The following configure options are used to specify each of them:

--build=build
The system on which the package is built.

--host=host
The system where built programs and libraries will run.

When the --host is used, configure will search for the cross-compiling suite for this platform. Cross-compilation tools commonly have their target architecture as prefix of their name. For instance my cross-compiler for MinGW32 has its binaries called i586-mingw32msvc-gcc, i586-mingw32msvc-ld, i586-mingw32msvc-as, etc.

[Dmitry Eremin (Inactive)]

You can specify --target option also the same as --host but the --host should be specified to avoid using cross compiler for tests during ./configure script execution.

[Robert Read (Inactive)]

Ah, my mistake: --target is only used when building a cross compiler - it's the architecture that the cross compiler will produce.

[Andreas Dilger]

Is there actually something that needs to be changed in the Lustre build environment for this to work, or is it working properly with the current --host and --build configure options?

[Dmitry Eremin (Inactive)]

Without http://review.whamcloud.com/5273 patch it doesn't work.

[Dmitry Eremin (Inactive)]

The config.log of the following command is attached (w/o the patch):

./configure --with-linux=/opt/intel/mic/src/card/kernel \
    --disable-server --without-o2ib \
    --host=x86_64-k1om-linux --build=x86_64-pc-linux

[Jay Lan (Inactive)]

If I have a chroot environment with
intel-mic-ofed-kmod-devel
intel-mic-ofed-libibscif-devel
and other supportive intel-mic-ofed rpms installed,
and specify " --with-o2ib=/usr/src/intel-mic-ofed-kmod" as a configure parameter, do I still need this patch? I built a lustre client this way it seemed to build OK.

[Andreas Dilger]

Jay, you will note that this patch has been marked as fixed in the 2.4.0 release, so no patch is necessary for that version.

[Jay Lan (Inactive)]

I meant to ask if the solution provided by this LU patch is needed even if I build in a chroot environment populated with those intel-mic-ofed rpms.

I built lustre-2.3.0 this way before I was aware of this LU ticket. If there was no lustre code changed, my build should be OK, right? The lustre client module was loaded OK.

[Dmitry Eremin (Inactive)]

This patch is required for 2.4 because of assembly code with is not supported by Xeon Phi. Actually tag 2.3.65 also contain the patch. Therefore you can build it without problem. For earlier 2.3 versions most probably you will have a problem with configure. But if you be able to compile this path is not required for functionality.