Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
Lustre 2.4.0
-
None
-
6682
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
Attachments
Issue Links
- links to
Activity
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.
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.
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
Without http://review.whamcloud.com/5273 patch it doesn't work.
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?
Ah, my mistake: --target is only used when building a cross compiler - it's the architecture that the cross compiler will produce.
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.
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.
$ 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
...
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)
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.