I'm starting to work with a Xeon Phi and I'm stuck trying to compile a simple C program to run it on the coprocessor. I've tried using icl and icc commands but I haven't got any luck.
1.- with icl
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\bin\intel64>icl test.c -o test.mic
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.185 Build 20180210
Copyright (C) 1985-2018 Intel Corporation. All rights reserved.
test.c
Microsoft (R) Incremental Linker Version 14.15.26726.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:test.mic
test.obj
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\bin\intel64>
then I tried to run test.mic on the Xeon Phi
[xeon#mic0 ~]$ ./test.mic
-sh: ./test.mic: cannot execute binary file
[xeon#mic0 ~]$
2.- with icc
C:\Intel\cc_android_2018.2.185\bin\intel64>icc test.c -o test.mic
Error: A license for (Comp-CL) could not be found.
License file(s) used were (in this order):
1. C:\Program Files (x86)\Common Files\\Intel\Licenses\NCOM_W___XXXX-XXXXXXXX.lic
2. C:\Intel\cc_android_2018.2.185\bin\intel64\..\..\Licenses
3. C:\Program Files\Common Files\Intel\Licenses\NCOM_W___XXXX-XXXXXXXX.lic
4. C:\Intel\cc_android_2018.2.185\bin\intel64\NCOM_W___XXXX-XXXXXXXX.lic
Please refer https://software.intel.com/en-us/faq/licensing#invalid-license-error for more information..
icc: error #10052: could not checkout FLEXlm license
I'm not sure about this error because I have the license.
The problem was the Intel Parallel Studio version I was using (Intel Parallel Studio 2018) . I downloaded Intel Parallel Studio 2017 Update 7 and the compilation worked. The command I was using:
icl /Qmic test.c -o test.out
And I was getting this error:
icl: command line remark #10148: option '/Qmic' not supported
Related
I want to build a c application with visual-studio build tool cl.exe by invoking nmake similar like make in **NIX systems. I have written a makefile. It cannot find include files and object files for linking. I couldn't find much reference how to link libraries.
CC=cl.exe
INC=-I../include
LIB=-L../lib
socket: socket.c
$(CC) socket.c $(INC) $(LIB) -lssl -lcrypto
output
D:\client>nmake
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl.exe socket.c -I../include -L../lib -lssl -lcrypto
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002 : ignoring unknown option '-L../lib'
cl : Command line warning D9002 : ignoring unknown option '-lssl'
cl : Command line warning D9002 : ignoring unknown option '-lcrypto'
socket.c
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:socket.exe
socket.obj
LINK : fatal error LNK1104: cannot open file 'Ws2_32.lib'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe"' : return code '0x2'
Stop.
the cl.exe does not use the gcc syntax for libraries and include files.
Here is a (usable but not perfect) example of how to specify the files:
cl main.c freetype.lib gdi32.lib glew.lib jpeg.lib
you might also want to read how to include in cl.exe
I have to automate couple of simple builds on windows.
I am able to generate debug information if I use specific target.
My Makefile
.c.obj:
#echo executing compile rule
$(cc) $(cdebug) $(cflags) $(cvars) $*.c
.obj.exe:
#echo executing linker rule
$(link) $(ldebug) $(conflags) -out:$# $** $(conlibs)
foo.exe: foo.obj
#echo executing target rule
$(link) $(ldebug) $(conflags) -out:$# $** $(conlibs)
nmake /f Makefile.win foo.exe : make Output:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
executing compile rule
cl -Zi -Od -DDEBUG -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS -D_X
86_=1 -DWIN32 -D_WIN32 -W3 -D_WINNT -D_WIN32_WINNT=0x0500 -DNTDDI_VERSION=0x050
00000 -D_WIN32_IE=0x0500 -DWINVER=0x0500 -D_MT -MTd foo.c
foo.c
executing target rule
link /DEBUG /DEBUGTYPE:cv /INCREMENTAL:NO /NOLOGO -subsystem:console,5.
0 -out:foo.exe foo.obj kernel32.lib ws2_32.lib mswsock.lib advapi32.lib
nmake /f Makefile.win bar.exe : make Output:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl bar.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
bar.c
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:bar.exe
bar.obj
Notice that none of the suffix rules were executed second time. What am I doing wrong?
I have added .SUFFIXES: .exe .obj at the top.
First be sure both .obj and .exe are in the suffixes list, or those suffix rules won't take effect:
.SUFFIXES: .obj .exe
Second, using $** is very odd. Why are you adding foo* to your link line? I would think you'd want something like $^ instead.
Other than that all I can suggest is you examine the actual linker lines that are printed by make in both situations and figure out what the difference is between them. You don't show that here.
GNU make takes the approach of modeling the entire dependency tree at once, and tracing the modified files all the way through to the output. This is great if make is the only build tool you use. This doesn't work well if you have very large projects, so you need to make them in a specific order. This doesn't work well if 'make' doesn't support some tools of your build process, so you would need to run make multiple times anyway.
nmake.exe takes the approach of doing the simplest possible thing: Only doing one pass at a time. It assumes it will be part of a larger tool chain. So if you have multi-pass dependencies, you will need multiple passes of nmake. If your build process requires more than 3 passes, you are probably doing A Bad Thing and you should fix your process. And for crying out loud, if you need multiple passes, just write a script to do it.
from here:
nmake inference rules limited to depth of 1
When I attempt to link from a makefile I get the following error:
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'.
Makefile Execution:
C:\Users\snmcdonald\Desktop\winMake2\winMake2>nmake "_DEBUG=" /f win2.mk build
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /ZI /Fo"Debug\\" /Fe"Debug\\" main.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
main.c
cl /c /ZI /Fo"Debug\\" /Fe"Debug\\" lib.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
lib.c
lib Debug\lib.obj /out:Debug\lib.lib
Microsoft (R) Library Manager Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
link Debug\main.obj Debug\lib.lib /out:Debug\main.exe
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
main.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specif
ication
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x450'
Stop.
However, if I rerun the exact same line that failed and link from the console I get a successful build. I am using the exact same lib and obj that were produced from my make file.
Console Execution:
C:\Users\snmcdonald\Desktop\winMake2\winMake2>link Debug\main.obj Debug\lib.lib /o
ut:Debug\main.exe
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
main.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specif
ication
C:\Users\SHANEM~1\Desktop\winMake2\winMake2>debug\main.exe
print from lib
I have included my makefile for reference.
Makefile
!ifdef _DEBUG
CC = cl
CFLAGS = /c /ZI
FILES = *.c
OUT = /Fo"Debug\\" /Fe"Debug\\"
LINKOUT = /out:Debug
DIR = Debug
!else
CC = cl
CFLAGS = /O2
FILES = *.c
OUT = /Fo"Release\\" /Fe"Release\\"
LINKOUT = /out:Release
DIR = Release
!endif
LIB = lib
LINK = link
RM = del
RMFLAGS = *.ojb *.exe 2>NUL
build: main.exe
clean:
$(RM) $(RMFLAGS)
rebuild: clean build
main.exe: main.obj lib.lib
$(LINK) $(DIR)\main.obj $(DIR)\lib.lib $(LINKOUT)\main.exe
lib.lib: lib.obj
$(LIB) $(DIR)\lib.obj $(LINKOUT)\lib.lib
main.obj:
$(CC) $(CFLAGS) $(OUT) main.c
lib.obj:
$(CC) $(CFLAGS) $(OUT) lib.c
Testing
I have tested this on both Visual C version 9 and version 10. I am confused why it would fail on my makefile but run successfully when manually entered on the command line.
Solution:
nmake /E /f win2.mk build
/E - overrides macro vars with environmental paths.
LIB = lib
That screws up the LIB environment variable. Yes, /E will fix it but your next project that actually needs lib.exe is going to fail. Pick another name, win32.mak uses "implib".
The file should exist in
...\Microsoft Visual Studio 8\VC\lib
It could be difference of environment variables setting. Check what are the enviroment variables setting when you run it manually from the command line.
http://us.generation-nt.com/answer/lnk1104-open-file-libcmt-lib-help-21575202.html
The LIB environment variable should
contain the path to your various lib
directories. You can also run the
VCVARS32.BAT file, which will
automatically set the environment up
for you. If you do a lot of command
line builds, I recommend creating a
shortcut that invokes the above
mentioned VSVARS32.BAT
Here is a very simple C program:
#include <stdio.h>
int main (int argc, char *argv[]) {
printf("sizeof(short) = %d\n",(int)sizeof(short));
printf("sizeof(int) = %d\n",(int)sizeof(int));
printf("sizeof(long) = %d\n",(int)sizeof(long));
printf("sizeof(long long) = %d\n",(int)sizeof(long long));
printf("sizeof(float) = %d\n",(int)sizeof(float));
printf("sizeof(double) = %d\n",(int)sizeof(double));
return 0;
}
While it compiles fine on Win32 (command line: cl main.c), it does not using the Win64 compiler ("c:\Program Files(x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\cl.exe" main.c). Specifically, it sais "error LNK2019: unresolved external symbol printf referenced in function main". As far as I understand this, it can not link to printf, right?
Obviously, I have Microsoft Visual C++ Compiler 2008 (Standard enu) x86 and x64 installed and am using the 64-bit flavor of Windows (7).
What is the problem here?
UPDATE:
OK, now I ran vcvarsall.bat amd64. It sais "The specified configuration type is missing. The tools for this configuration might not be installed.". As mentioned, the compiler clearly is installed??
If you look at vcvarsall.bat it will print the specified configuration missing statement if certain batch files are missing.
For the amd64 option this file must exist:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat
There's something wrong with your setup. It compiles & link fine for me.
D:>cl test.cpp Microsoft (R) C/C++
Optimizing Compiler Version
15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights
reserved.
test.cpp Microsoft (R) Incremental
Linker Version 9.00.30729.01 Copyright
(C) Microsoft Corporation. All rights
reserved.
/out:test.exe test.obj
D:>
Did you run vcvarsall.bat with the right options to set up the environment variables before you try running cl.exe? Something along the line of
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64
Are you on a 32bit or 64bit system? I'm guessing from the path that the 64bit standard libraries aren't available, at least not in that directory.
I want to compile C code from the Command Prompt in Windows. I have added the environment variable to the PATH and I can compile .cs files with: csc app.cs
That's OK, but how do I compile app.c?
You do this:
cl app.c
Here's a complete transcript, including setting up the environment for Visual Studio 2005 (change "8" to "9.0" for Visual Studio 2008).
C:\src\tests>"\Program Files (x86)\Microsoft Visual Studio 8\vc\bin\vcvars32.bat"
Setting environment for using Microsoft Visual Studio 2005 x86 tools.
C:\src\tests>type app.c
#include <stdio.h>
int main(void)
{
printf("Hello world!\n");
return 0;
}
C:\src\tests>cl app.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
app.c
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:app.exe
app.obj
C:\src\tests>app
Hello world!
MinGW provides a popular command-line GCC compiler for Windows.
open command prompt
type path c:\tc\bin
goto your project folder in command prompt
type tcc filename.c
after compilation type filename