topic This should just require in Software Archive

Build Native Libraries on windows

jasno — Thu, 19 Dec 2013 11:45:30 GMT

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.

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 ?

To follow up my own post, I

jasno — Thu, 19 Dec 2013 11:52:05 GMT

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

When making a linux hosted

TimP — Thu, 19 Dec 2013 12:23:00 GMT

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.

Quote:Tim Prince wrote:

jasno — Thu, 19 Dec 2013 12:32:34 GMT

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.

I have just noticed that,

jasno — Thu, 19 Dec 2013 12:36:16 GMT

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

This should just require

Kevin_D_Intel — Thu, 19 Dec 2013 12:36:41 GMT

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.

Quote:Kevin Davis (Intel)

jasno — Thu, 19 Dec 2013 12:43:20 GMT

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

Whether in PATH or run

Kevin_D_Intel — Thu, 19 Dec 2013 13:26:14 GMT

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.

Quote:jasno wrote:

jasno — Thu, 19 Dec 2013 13:27:42 GMT

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

For now the latter. i.e. "Or

Kevin_D_Intel — Thu, 19 Dec 2013 13:42:10 GMT

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.

Quote:Kevin Davis (Intel)

jasno — Thu, 19 Dec 2013 13:48:15 GMT

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 ?

The directory changes make it

Kevin_D_Intel — Thu, 19 Dec 2013 13:55:12 GMT

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?

Quote:Kevin Davis (Intel)

jasno — Thu, 19 Dec 2013 14:01:49 GMT

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

Ok, that’s actually helpful.

Kevin_D_Intel — Thu, 19 Dec 2013 14:19:47 GMT

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.

Quote:Kevin Davis (Intel)

jasno — Thu, 19 Dec 2013 14:41:41 GMT

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

Quote:jasno wrote:

jasno — Thu, 19 Dec 2013 15:39:26 GMT

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

Quote:Kevin Davis (Intel)

jasno — Thu, 19 Dec 2013 16:42:00 GMT

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

You do something like below.

Kevin_D_Intel — Thu, 19 Dec 2013 17:52:00 GMT

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.

-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).

It seems like this problem

PKM — Thu, 31 Jul 2014 06:27:55 GMT

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?

The fix for the issue

Kevin_D_Intel — Thu, 31 Jul 2014 10:42:51 GMT

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.