Build Native Libraries on windows

[jasno]

Hi,

    I am trying to build a library (static and shared) for the MIC on windows. I have compiled my src using the /Qmic flag but now I don't get how to generate a library. For example I compile a src file as:

ifort /Qmic -nologo -auto -fp -align array64byte -fp-model precise -mp1 -mkl -openmp -fpp -c -o performance_parameters_sb1.o c:/modules/performance_parameters_sb1.f90

then have tried these three methods to turn it into being a static library . . .

xilink -lib /OUT:c:/BUILD_win64-MIC_MKL_64/engine/LIBS/mkl/perflibs/performance_parameters_sb1.a c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o
xilib: executing 'k1om-mpss-linux-ar.exe'
xilib: executing 'lib'
Microsoft (R) Library Manager Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/OUT:c:/BUILD_win64-MIC_MKL_64/engine/LIBS/mkl/perflibs/performance_parameters_sb1.a
c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o
c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o :
fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F88

and I also tried

$ xilib /OUT:c:/BUILD_win64-MIC_MKL_64/engine/LIBS/mkl/perflibs/performance_parameters_sb1.a c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o

xilib: executing 'k1om-mpss-linux-ar.exe'
xilib: executing 'lib'
Microsoft (R) Library Manager Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/OUT:c:/BUILD_win64-MIC_MKL_64/engine/LIBS/mkl/perflibs/performance_parameters_sb1.a
c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o
c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o :
fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F88

so I went looking for the linux tools and tried them directly:

k1om-mpss-linux-ar.exe ar c:/BUILD_win64-MIC_MKL_64/engine/LIBS/mkl/perflibs/performance_parameters_sb1.a c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o
C:\Program Files\Intel\MPSS\x86_64-mpsssdk-linux\usr\bin\k1om-mpss-linux\k1om-mpss-linux-ar.exe:
c:/BUILD_win64-MIC_MKL_64/engine/OBJECTS/performance_parameters_sb1.o: File format not recognized

What is the correct way to do this ?

[jasno]

To follow up my own post, I now notice that, despite the errors, a .a file is created for the first two cases (xilib and xilink) but not using the k1om-mpss-linux-ar.exe command directly. Not sure if this is a valid file (will try and use it and see), but I need to find a way to generate the libraries without the command throwing an error as it causes make to stop. Any ideas ?

--

jason

[TimP]

When making a linux hosted build, it has been necessary to use xiar for this purpose.

I think it's dangerous to sprinkle in possibly conflicting options (-fp -fp-model precise -mp1) or to attempt to pre-link against mkl libraries when making your own library.  As far as I know, -mp1 is available only as a substitute for the obsoleted option of that spelling.

[jasno]

Tim Prince wrote:

When making a linux hosted build, it has been necessary to use xiar for this purpose.

I don't think that exists on windows.

Tim Prince wrote:

I think it's dangerous to sprinkle in possibly conflicting options (-fp -fp-model precise -mp1) or to attempt to pre-link against mkl libraries when making your own library.  As far as I know, -mp1 is available only as a substitute for the obsoleted option of that spelling.

Thanks for that, I'll have a tidy up of the flags in the build system.

[jasno]

I have just noticed that, despite the error messages, a .a file is actually created for the first two options (but not calling the k1om-mpss-linux-ar.exe command directly.) I'll take a look at this file and see if it is what I need. However, I still need the command to not produce errors as this causes make to stop.

--

jason

[Kevin_D_Intel]

This should just require compiling to object using /Qmic and using xiar. It appears you are running MPSS 3.1 and I'm seeing that xiar is not compensating for some k1om binutils name changes under MPSS 3.1. I'll figure out why and what's needed and post an update shortly.

[jasno]

Kevin Davis (Intel) wrote:

This should just require compiling to object using /Qmic and using xiar. It appears you are running MPSS 3.1 and I'm seeing that xiar is not compensating for some k1om binutils name changes under MPSS 3.1. I'll figure out why and what's needed and post an update shortly.

It might just be that my PATH is wrong as xiar doesn't exist, but if search for it in file manager it is there. I'll try adding its location to my path and see how I get on with it, thanks.

--

jason

[Kevin_D_Intel]

Whether in PATH or run explicitly, you'll likely face this:

C:\temp\> "C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\intel64_mic\xiar" rcs libbar.a bar.o
Error: fread returned 1555 bytes (719840 expected)
Error: cannot read section headers
xiar: executing 'x86_64-k1om-linux-ar.exe'
xiar: error #10037: could not find 'x86_64-k1om-linux-ar.exe'
xiar: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\INTEL6~1\xild') failed, errno=0

The underlying "ar" under the MPSS 3.1 is now k1om-mpss-linux-ar.exe and there are also other directory name changes on top of this.

[jasno]

jasno wrote:

Quote:

Kevin Davis (Intel) wrote:

This should just require compiling to object using /Qmic and using xiar. It appears you are running MPSS 3.1 and I'm seeing that xiar is not compensating for some k1om binutils name changes under MPSS 3.1. I'll figure out why and what's needed and post an update shortly.

It might just be that my PATH is wrong as xiar doesn't exist, but if search for it in file manager it is there. I'll try adding its location to my path and see how I get on with it, thanks.

So having looked into it a little, I see that I have "C:\Program Files (x86)\Intel\Composer XE 2013 SP1.139\bin\intel64" in my path and so I pick up ifort and icl from this location. xiar seems only to be in "C:\Program Files (x86)\Intel\Composer XE 2013 SP1.139\bin\intel64_mic" which is not in my path, but which also includes an ifort command (but no icl, rather it has icc). So whats the correct thing for me to be using ? Should my PATH be the latter option (C:\Program Files (x86)\Intel\Composer XE 2013 SP1.139\bin\intel64_mic) and should I use ifort from that directory ? Or should I add it to the end of my PATH so that I can call xiar directly but still pick up the other versions of ifort and icl ?

--

jason

[Kevin_D_Intel]

For now the latter. i.e. "Or should I add it to the end of my PATH so that I can call xiar directly but still pick up the other versions of ifort and icl"

It is important to always use the compiler drivers (ifort/icl) from the intel64 directory and allow them to call intel64_mic versions as designed when offload code is detected in the source file or /Qmic is specified.

[jasno]

Kevin Davis (Intel) wrote:

Whether in PATH or run explicitly, you'll likely face this:

C:\temp\> "C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\intel64_mic\xiar" rcs libbar.a bar.o
Error: fread returned 1555 bytes (719840 expected)
Error: cannot read section headers
xiar: executing 'x86_64-k1om-linux-ar.exe'
xiar: error #10037: could not find 'x86_64-k1om-linux-ar.exe'
xiar: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\INTEL6~1\xild') failed, errno=0

The underlying "ar" under the MPSS 3.1 is now k1om-mpss-linux-ar.exe and there are also other directory name changes on top of this.

What about if I make a copy of the new one with the old name ? Or do the other directory changes make it a non starter ?

[Kevin_D_Intel]

The directory changes make it a non-starter. I'm closing in on a work around. Do you happen to have a system available with MPSS 2.1 still installed?

[jasno]

Kevin Davis (Intel) wrote:

The directory changes make it a non-starter. I'm closing in on a work around. Do you happen to have a system available with MPSS 2.1 still installed?

We only have the one Windows system. However, while 2.1 is not the active installation, I think the MPSS 2.1 directory is still in place (renamed MPSS_old2) if it is just files in that directory that you are after . . .

--

jason

[Kevin_D_Intel]

Ok, that’s actually helpful. Until I can speak with the driver developer, try this.

Before executing xiar, set the environment variable MIC_SYSROOT (as shown below) and then unset it after running xiar to avoid confusing the compiler driver invocations that occur after running xiar.  For example:

SET MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"
xiar ….
SET MIC_SYSROOT=

Or do the equivalent within your makefile.

[jasno]

Kevin Davis (Intel) wrote:

Ok, that’s actually helpful. Until I can speak with the driver developer, try this.

Before executing xiar, set the environment variable MIC_SYSROOT (as shown below) and then unset it after running xiar to avoid confusing the compiler driver invocations that occur after running xiar.  For example:

SET MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"
xiar ….
SET MIC_SYSROOT=

Or do the equivalent within your makefile.

OK, I'll give that a go and get back to you, might take a while to reconfigure things and to start using xiar within our build system.

--

jason

[jasno]

jasno wrote:

Quote:

Kevin Davis (Intel) wrote:

Ok, that’s actually helpful. Until I can speak with the driver developer, try this.

Before executing xiar, set the environment variable MIC_SYSROOT (as shown below) and then unset it after running xiar to avoid confusing the compiler driver invocations that occur after running xiar.  For example:

SET MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"
xiar ….
SET MIC_SYSROOT=

Or do the equivalent within your makefile.

I'm afraid that doesn't work for me. If I have a directory of objects, compiled using ifort and /Qmic, and want to build the library foo.a I am doing:

SET MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"

C:\test5\test_g05>xiar -rs foo.a *.o
xiar: executing 'x86_64-k1om-linux-ar.exe'
xiar: error #10037: could not find 'x86_64-k1om-linux-ar.exe'
xiar: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1.139\bin\INTEL6~1\xild') failed, errno=0

C:\tmp\test5\test_g05>dir %MIC_SYSROOT%
 Volume in drive C has no label.
 Volume Serial Number is 22E4-62C4

 Directory of C:\Program Files\Intel\MPSS_old2\sdk

23/09/2013  17:02    <DIR>          .
23/09/2013  17:02    <DIR>          ..
17/07/2013  12:33    <DIR>          linux-k1om-4.7
               0 File(s)              0 bytes
               3 Dir(s)  872,776,159,232 bytes free

--

jason

[jasno]

Kevin Davis (Intel) wrote:

Ok, that’s actually helpful. Until I can speak with the driver developer, try this.

Before executing xiar, set the environment variable MIC_SYSROOT (as shown below) and then unset it after running xiar to avoid confusing the compiler driver invocations that occur after running xiar.  For example:

SET MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"
xiar ….
SET MIC_SYSROOT=

Or do the equivalent within your makefile.

OK, so just using the k1om-mpss-linux-ar.exe command directly seems to work, I just gave it the wrong args before. Still can't get xiar to work but doing

 k1om-mpss-linux-ar.exe rs foo.a *.o

ifort /Qmic -o test_g05saf.exe test_g05.f90 foo.a -I./modules_native -mkl

gives an exe that can be copied to the MIC and run successfully. I can just use that for now.

--

jason

[Kevin_D_Intel]

You do something like below. I tailored the demonstration below to your config.

bar.f90
===============
subroutine bar
  print*,"MIC: in bar...."
end subroutine bar
 

foo.f90
================
program foo
!DIR$ ATTRIBUTES OFFLOAD : mic :: bar

  print*,"Host: in foo..."

  !DIR$ OFFLOAD begin target(mic)
    call bar
  !DIR$ end OFFLOAD
end program foo

C:\> ifort /Qmic -fpic -c bar.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.139 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

C:\> set MIC_SYSROOT="C:\Program Files\Intel\MPSS_old2\sdk"

C:\> "C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\intel64_mic\xiar" rcs libbar.a bar.o
Error: fread returned 1555 bytes (719840 expected)
Error: cannot read section headers
xiar: executing 'x86_64-k1om-linux-ar.exe'

C:\> set MIC_SYSROOT=

C:\> ifort foo.f90 /Qoffload-option,mic,link,"-L. -lbar"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.139 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:foo.exe
-subsystem:console
foo.obj
C:\Users\xxxxxx\AppData\Local\Temp\2\44884.obj
-defaultlib:liboffload
-defaultlib:libiomp5md
ofldbegin.obj
ofldend.obj

C:\> .\foo.exe
 Host: in foo...
 MIC: in bar....

You can (as you did) also build a native executable and link the library as you showed too.

You can safely ignore the error from xiar that appears above. That's known to be benign and will be fixed in a future update.

You probably could use the k1om binutils "ar" for most programs but not when IPO optimization is used.

I submitted this to Development (under the internal tracking id below) for further investigation.

(Internal tracking id: DPD200250854)
(Resolution Update on 09/15/2014): This defect is fixed in the Intel® Composer XE 2013 SP1 Update 4 release (2013.1.4.211 - Linux) -AND- the Intel® Parallel Studio XE 2015 Initial Release (2015.0.090 - Linux).

[PKM]

It seems like this problem was never fully resolved, as I am seeing almost exactly the same thing in the latest version of parallel studio. I am compiling a c++ project that includes offload regions and when the linking stage is reached I get the error:

1>  xilib: executing 'k1om-mpss-linux-ar.exe'
1>xilib : error #10037: could not find 'ar.exe'
1>xilib : error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\Intel64\xilink.exe') failed, errno=0

Any suggestions for a fix or workaround?

[Kevin_D_Intel]

The fix for the issue discussed in this thread relates only to building native with /Qmic which is only supported using the command line. That fix (to DPD200250854) is expected to be in the next Composer XE 2013 SP1 Update 4 tentatively scheduled for release next month (mid-August).

The issue you experienced involves building a static library containing offloaded code under the Visual Studio IDE. There are two underlying issues impacting that. The first you experienced (ar.exe not found) and a second that surfaces after working around the first, and it takes some acrobatics both in and outside the IDE to work around both.

The fix for the missing ar.exe issue (DPD200256240) is also expected to be in the next Composer XE 2013 SP1 Update 4 release. To work around this issue one needs have a copy of C:\Program Files\Intel\MPSS\sdk\linux-k1om-4.7\bin\x86_64-k1om-linux-ar.exe  named as “ar.exe” within any location that appears in your PATH setting; however, doing so leads to another error so you must also work around as discussed below.

For a quick work around for the missing ar.exe issue, under a command-prompt running as Administrator, you can create a symbolic-link with mklink as follows:

mklink "C:\Program Files\Intel\MPSS\bin\ar.exe" "C:\Program Files\Intel\MPSS\sdk\linux-k1om-4.7\bin\x86_64-k1om-linux-ar.exe"

For example:

C:\> mklink "C:\Program Files\Intel\MPSS\bin\ar.exe" "C:\Program Files\Intel\MPSS\sdk\linux-k1om-4.7\bin\x86_64-k1om-linux-ar.exe"
symbolic link created for C:\Program Files\Intel\MPSS\bin\ar.exe <<===>> C:\Program Files\Intel\MPSS\sdk\linux-k1om-4.7\bin\x86_64-k1om-linux-ar.exe

Once you work around that issue, you hit another defect when building under the MSVS IDE (DPD200252338 - discussed here: http://software.intel.com/forums/topic/498728) where the path to the <file>MIC.o files is mangled (Windows style backslashes are dropped) and the invocation of ar.exe fails with something like:

1>xilib: executing 'x86_64-k1om-linux-ar.exe'
1>ar.exe: x64Debugtbo_sort_libMIC.o: No such file or directory

For that issue there is no work around that permits building the static library entirely under the MSVS IDE, instead you compile under the IDE and link outside the IDE. As discussed in the other cited forum thread, you perform the build under the IDE which compiles and fails as noted above. After the xilib failure under the IDE, you then execute the xilib command under an Intel compiler initialized command-prompt ( Start Menu > All Programs > Intel Parallel Studio XE 2013 > Command Prompt > Parallel Studio XE with Intel Compiler XE v14.0 Update 3) to create the static library.

In my case above, I would cd into the static library Project’s “x64\Debug” folder and manually execute:

xilib -out:..\MyStaticLib.lib *.obj

You do the same for the Release build and just cd into that output directory accordingly.

One other change that you must make for this to work relates to a Solution containing the static library and other projects (like a console app) where they are configured with the static library being a dependent project of the other project(s). In a Solution with project dependencies setup, when you build the other project that depends on the static library, the static library project is rebuilt which includes removing the good static library that you just built manually. To avoid this situation you must temporarily undo your project dependencies and then add a hard reference to the static library in the dependent project under Properties > Linker > Additional Dependencies.

My example Solution here contains two projects, a console app with a dependency on my static library. After  undoing the project dependencies (Project > Project Dependencies), for the console application, under Properties > Linker > Additional Dependencies I added the following:  $(SolutionDir)\MyStaticLib\$(OutDir)\MyStaticLib.lib

Our apologies for this tangled mess. I do expect all this will be sorted out in the Composer XE 2013 SP1 Update 4 release next month. I will start evaluating internal packages with these fixes as those become available shortly to ensure all this is fixed.

[PKM]

Thanks Kevin.

My file was in c:\Program Files\Intel\MPSS\x86_64-mpsssdk-linux\usr\bin\k1om-mpss-linux\k1om-mpss-linux-ar.exe, but I got it working the way you described ...

Now my problem is that it doesn't seem like the .lib actually contains the MIC branch of the code. I compiled it with -offload-attribute-target=mic, but the code fails to execute on the very first call to an offload region as seen in the report below.

I performed the linking with the line you suggested (xilib -out:..\MyStaticLib.lib *.obj). Do I perhaps need to do something special also for the .o files?

Thanks,

C

[Offload] [HOST]  [State]   Initialize logical card 0 = physical card 0
[Offload] [HOST]  [State]   Initialize logical card 1 = physical card 1
[Offload] [MIC 0] [File]            P:\casper.kirkegaard\ftn\paralution-0.7.0\sr
c\base\mic\mic_allocate_free.cpp
[Offload] [MIC 0] [Line]            48
[Offload] [MIC 0] [Tag]             Tag 0
[Offload] [HOST]  [Tag 0] [State]   Start Offload
[Offload] [HOST]  [Tag 0] [State]   Initialize function __offload_entry_mic_allo
cate_free_cpp_48allocate__78808b782225fceaae4b3931b82620951600129922
[Offload] [HOST]  [Tag 0] [State]   Create buffer from Host memory
[Offload] [HOST]  [Tag 0] [State]   Create buffer from MIC memory
[Offload] [HOST]  [Tag 0] [State]   Send pointer data
[Offload] [HOST]  [Tag 0] [State]   CPU->MIC pointer data 0
[Offload] [HOST]  [Tag 0] [State]   Gather copyin data
[Offload] [HOST]  [Tag 0] [State]   CPU->MIC copyin data 0
[Offload] [HOST]  [Tag 0] [State]   Compute task on MIC
[Offload] [HOST]  [Tag 0] [State]   Receive pointer data
[Offload] [HOST]  [Tag 0] [State]   MIC->CPU pointer data 0
[Offload] [MIC 0] [Tag 0] [State]   Start target function __offload_entry_mic_al
locate_free_cpp_48allocate__78808b782225fceaae4b3931b82620951600129922
[Offload] [MIC 0] [State]   Unregister data tables
offload error: cannot find offload entry __offload_entry_mic_allocate_free_cpp_4
8allocate__78808b782225fceaae4b3931b82620951600129922