In windows 7 64 bit, my makefile builds with mks make are fine if all the source files are .cu files
make all
[
nvcc -gencode=arch=compute_20,code="sm_20,compute_20"
–machine 64 -ccbin ‘c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN’
-Xcompiler ‘/EHsc /W3 /nologo /O2 /Zi /MT -I … ’
-I’C:/Users/myname/cuda/common/inc’
-I’C:/Users/myname/cuda/shared/inc’
-I’C:/Users/myname/cuda/cbe/common’
-maxrregcount=32 -Xptxas=“-v” --compile -o aop.obj aop.cu
]
if some of the source files are .c files, I guess I need to use the amd64 version of cl
if I want to link the .obj in with the .cu .obj files. (If I try to use the x86 cl to make the obj I get the LNK1112
: fatal error LNK1112: module machine type ‘X86’ conflicts with target machine type ‘x64’
OK so I use the amd64 compiler version of cl, and make the .obj I want to link in with that, but the linker cant find the symbols from the .c obj I want to link in.
I want to do this because this .cu module is going to be a part of a large system of .c programs, and only one of them is a .cu.
Is there some way I can easily make the symbols inside the .obj compiled from the .c using amd64/cl (so it is 64 bit) compatible with the externs I generate in my .cu ? I like static linking and not run time if possible. As a last resort, would my .cu program work with a DLL and do I have to make the DLL with the amd64 compiler objects
Here is the link step that tries to link the .cu obj with the .c obj made with the amd64
version of cl.
[
link -OUT:aop.exe
-INCREMENTAL:NO
-NOLOGO
-LIBPATH:“C:/Users/myname/cuda/libs”
-LIBPATH:“C:/Users/myname/cuda/libs/x64”
-LIBPATH:“C:/Users/myname/cuda/common/lib”
-LIBPATH:“C:/Users/myname/cuda/shared/lib”
-LIBPATH:‘C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/lib/amd64’
-LIBPATH:‘C:/Program Files/Microsoft SDKs/Windows/v6.0A/lib/x64’
-SUBSYSTEM:CONSOLE
-DYNAMICBASE:NO -MACHINE:X64
-OPT:REF
-OPT:NOICF
-ERRORREPORT:PROMPT aop.obj aopdat.obj cudart.lib cutil64.lib
shrUtils64.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib odbc32.lib odbccp32.lib
]
aop.obj : error LNK2019: unresolved external symbol
“double __cdecl timeToDouble(__int64,__int64)” (?timeToDouble@@YAN_J0@Z)
referenced in function main
aop.obj : error LNK2019: unresolved external symbol
“__int64 __cdecl ProgramTimeStamp(void)” (?ProgramTimeStamp@@YA_JXZ)
referenced in function main
aop.obj : error LNK2001: unresolved external symbol “double * R22” (?R22@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R35” (?R35@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R69” (?R69@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R67” (?R67@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R68” (?R68@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R84” (?R84@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R112” (?R112@@3PANA)
aop.obj : error LNK2001: unresolved external symbol “double * R113” (?R113@@3PANA)
aop.exe : fatal error LNK1120: 10 unresolved externals
The internal contents of the aopdat.obj contain the required names but apparently
not exactly enough
nm aopdat.obj
0:0000012 ? $pdata$ProgramTimeStamp
0:0000000 ? $pdata$timeToDouble
0:0000008 ? $unwind$ProgramTimeStamp
0:0000000 ? $unwind$timeToDouble
0:8606238 a @comp.id
0:0000112 T ProgramTimeStamp
0:0023040 D R112
0:0034560 D R113
0:0000000 D R22
0:0011520 D R35
0:0046080 D R67
0:0057600 D R68
0:0069120 D R69
0:0080640 D R84
0:0000000 U __imp_QueryPerformanceCounter
0:0000000 U __imp_QueryPerformanceFrequency
0:0000000 U _fltused
0:0000000 T timeToDouble