Build Native Libraries on windows

Build Native Libraries on windows

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 ?

27 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

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

Citação:

Tim Prince escreveu:

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

I don't think that exists on windows.

Citação:

Tim Prince escreveu:

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

Citação:

Kevin Davis (Intel) escreveu:

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

Citação:

jasno escreveu:

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

Citação:

Kevin Davis (Intel) escreveu:

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 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?

Citação:

Kevin Davis (Intel) escreveu:

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

Citação:

Kevin Davis (Intel) escreveu:

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

Citação:

jasno escreveu:

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

Citação:

Kevin Davis (Intel) escreveu:

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

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

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

Ok. The location of x86_64-k1om-linux-ar.exe that I noted was MPSS 2.1 specific; the location of yours is for MPSS 3.x. Thanks for noting that.

Nothing is needed for handling the .o files. Those are handled invisibly by the xilib and other tools to create the corresponding MIC side static library at the same time the CPU-side static lib is created.

Your trace shows a routine is called in the offload section that has not been resolved in the offload image. That can be due to lacking the target(mic) decoration as you suspected; however, it appears the xilib command you cited from earlier thread is likely the cause. The earlier suggestions to include “..\” in the -out: argument is now ill-advised and leads to unwanted mangling of the MIC-side static library name and placement of it. Perhaps something else changed since the time I offered that advice to the release of newer Composer XE SP1 releases.

For now do not use the “..\” path component in the xilib command and just allow xilib to create both the CPU-side and MIC-side static libraries in the same directory as the .obj files. (I will edit that earlier post and remove the suggestion of placing the resulting .lib with a path component on -out: and just suggest it be created in the current folder)

You might check your build for similar name mangling and unexpected placement of the <file>MIC.a library based the details in my example below.

Here’s the mangling of the MIC-side library that I see trying to use the earlier advice. The name of the MIC-side library includes “..” where the backslash was dropped and note the library is created in the same directory as the .obj files, whereas the CPU-side library was placed in the parent folder; thus ..\ was handled properly.

C:\DPD200256240\StaticLib_only\MyStaticLib\x64\Debug> xilib -out:..\MyStaticLib.lib *.obj
xilib: executing 'x86_64-k1om-linux-ar.exe'
xilib: executing 'lib'
Microsoft (R) Library Manager Version 11.00.60315.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:..\MyStaticLib.lib
tbo_sort_lib.obj

C:\DPD200256240\StaticLib_only\MyStaticLib\x64\Debug> dir *MyStati*
 Volume in drive C has no label.

 Directory of C:\DPD200256240\StaticLib_only\MyStaticLib\x64\Debug

07/31/2014  08:09 AM            49,800 ..MyStaticLibMIC.a
               1 File(s)         49,800 bytes
               0 Dir(s)  86,699,732,992 bytes free

C:\DPD200256240\StaticLib_only\MyStaticLib\x64\Debug> dir ..\MyStat*
 Volume in drive C has no label.

 Directory of C:\DPD200256240\StaticLib_only\MyStaticLib\x64

07/31/2014  08:09 AM            41,684 MyStaticLib.lib
               1 File(s)         41,684 bytes
               0 Dir(s)  86,699,732,992 bytes free

 

Thanks Kevin

My files also had the two dangling dots and your suggestion resolved that problem. However, even after relinking i still have the exact same problem in the program where i want to use the static library ... It still seems that the MIC routines are not being linked at all.

One thing that could potentially explain this is a well hidden "no such file or directory" in the build log as seen below - but I have no idea what the message is relating to. As you can see from the command line i link both the main library paralution.lib and paralutionMIC.a explicitly, since i am not sure whether the MIC file is passed to the MIC linker implicitly. Removing the explicit link to the MIC library have no influence on the outcome.

Any further suggestions?

Link /OUT:"x64\Debug\Console1.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"p:\casper.kirkegaard\ftn\steen test project\Console1\Console1\paralution bins" /qoffload-ldopts="-lifcoremt c:\temp\ParalutionMIC.a" /MANIFEST /MANIFESTFILE:"P:\casper.kirkegaard\ftn\steen test project\Console1\Console1\x64\Debug\Console1.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"P:\casper.kirkegaard\ftn\steen test project\Console1\Console1\x64\Debug\Console1.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"P:\casper.kirkegaard\ftn\steen test project\Console1\Console1\x64\Debug\Console1.lib" paralution_fortran.obj paralution.lib "x64\Debug\iters.obj" "x64\Debug\blassm.obj" "x64\Debug\itaux.obj" "x64\Debug\unary.obj" "x64\Debug\inout.obj" "x64\Debug\ilut.obj" "x64\Debug\formats.obj" "x64\Debug\qsort.obj" "x64\Debug\mError.obj" "x64\Debug\mTicToc.obj" "x64\Debug\matvec.obj" "x64\Debug\GaussDirectSol.obj" "x64\Debug\mArrays.obj" "x64\Debug\mSparseMatrix.obj" "x64\Debug\Console1.obj"

No such file or directory

Link: executing 'link'

paralution_fortran.obj : warning LNK4204: 'P:\casper.kirkegaard\ftn\steen test project\Console1\Console1\x64\Debug\vc110.pdb' is missing debugging information for referencing module; linking object as if no debug info

 

 

I have not been able to recreate the error yet so I do not know what is causing that. I thought maybe a path with embedded spaces but that works for me. I believe the error is from the MS linker side.

When specifying the static library (that contains the offload code) for linking within another project, you only specify the Windows (i.e. CPU-side) .lib name. It will be passed accordingly to the MIC-side link in the form of the .a name.

As noted earlier, you must undo the project dependencies (Project > Project Dependencies) and then for the console application, under Properties > Linker > Additional Dependencies, add only a reference to the CPU-side name. For my example discussed earlier I only specified the following under this property setting:  $(SolutionDir)\MyStaticLib\$(OutDir)\MyStaticLib.lib

Also make sure that if you relocate your static library w/offload somewhere that you relocate both the .lib and MIC.a so as to keep them side-by-side always. Our next 15.0 release merges the .lib/.a into a single .lib image so the handling is more natural to Windows. The same applies to a dynamic library where the.dll/.so are merged into a single .dll.

 

Thanks Kevin

15.0 is due later this month right? In that case I think it will be better if I postpone further work on the project until after the release ..

C

Yes, that's our target and we appear to be on track.

I confirmed the defects (DPD200250854, DPD200256240) mentioned in replies #18 and #20 are both 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).

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!