0

I'm porting a GPU application to Windows, using MSVC, which doesn't seem to play very nice with NVCC. I have separated the compiling and linking phases. nvcc will pre-process only the cuda files:

nvcc -dc -ccbin cl somefile.cu

and cl will compile everything else:

cl anotherfile.c

This separation was necessary, since many MSVC flags (excluded here) didn't jive with nvcc's wrapping of cl.exe (a related symptom here).

With compiling done, there are two ways I can do the linking.

  1. use nvcc to link only the CUDA device code, and then use link.exe to link everything, as per this guide.

As hard as I tried, I could not get link to find the CUDA headers, nor could I find any doc about how to point link to the cudart library. If only it were as easy as their g++ example!

  1. let nvcc do all the linking.

According to the doc however, there is "no option" to jump to the linking stage. So when I try to link everything, using...

nvcc somefile.o anotherfile.o -o app.exe

I get some warnings from cl!

cl : Command line warning D9024 : unrecognized source file type 'somefile.o', object file assumed
cl : Command line warning D9024 : unrecognized source file type 'anotherfile.o', object file assumed

Naturally, nvcc assumes these object files are source code and sends them to cl, because the doc includes:

Note that nvcc does not make any distinction between object, library or resource files.

Of course cl is complaining - these object files should be passed straight to the linker. I know link does eventually get invoked, beause I pass it some unrelated arguments with -Xlinker. After these warnings, app.exe is indeed compiled.

Despite the doc indicating there is no linker phase argument, how can I force nvcc to just link the objects, and not incorrectly pass them to cl? There is no way to suppress these warnings (at least not without being condemned by the stackoverflow community).

Anti Earth
  • 4,671
  • 13
  • 52
  • 83
  • even the [-link](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#options-for-specifying-compilation-phase-link) flag specifies to "*compile* and link", woe! – Anti Earth Apr 12 '20 at 21:36

1 Answers1

-1

check out my cuda code from http://github.com/fangq/mcx

you can compile it on Windows in Cygwin64/MSYS2 terminal, go to mcx/src folder, and type "make", this is what I see

nvcc -c -g -lineinfo -Xcompiler -Wall -Xcompiler "/openmp /W0" -DSAVE_DETECTORS -use_fast_math -arch=sm_30 -DMCX_TARGET_NAME='"Fermi MCX"' -DUSE_ATOMIC -use_fast_math -o mcx_core.obj  mcx_core.cu
mcx_core.cu
e:\gitroot\project\github\mcx\src\mcx_core.cu(2042) : warning C4701: potentially uninitialized local variable 'gsrcpattern' used
e:\gitroot\project\github\mcx\src\mcx_core.cu(2042) : warning C4703: potentially uninitialized local pointer variable 'gsrcpattern' used
nvcc -I/usr/local/cuda/include -I"/lib/include" -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp -c -o mcx_utils.obj  mcx_utils.c
mcx_utils.c
nvcc -I/usr/local/cuda/include -I"/lib/include" -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp -c -o mcx_shapes.obj  mcx_shapes.c
mcx_shapes.c
nvcc -I/usr/local/cuda/include -I"/lib/include" -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp -c -o tictoc.obj  tictoc.c
tictoc.c
nvcc -I/usr/local/cuda/include -I"/lib/include" -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp -c -o mcextreme.obj  mcextreme.c
mcextreme.c
nvcc -I/usr/local/cuda/include -I"/lib/include" -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp -c -o cjson/cJSON.obj  cjson/cJSON.c
cJSON.c
nvcc mcx_core.obj mcx_utils.obj mcx_shapes.obj tictoc.obj mcextreme.obj cjson/cJSON.obj -o ../bin/mcx -L"/lib/x64" -lcudart -Xcompiler /openmp
mcx_core.obj
mcx_utils.obj
mcx_shapes.obj
tictoc.obj
mcextreme.obj
cJSON.obj
   Creating library ../bin/mcx.lib and object ../bin/mcx.exp

it compiles each c unit, and link .obj files as expected, I don't see anything wrong.

FangQ
  • 1,444
  • 10
  • 18
  • Thanks for your answer, though I'm compiling specifically with MSVC, and asking about separation of compiling and linking (which your build doesn't do) – Anti Earth Apr 17 '20 at 14:51
  • No, my commands do separate the compilation from linking (the last command), and nvcc was configured to call msvc for both compiling and linking. – FangQ Apr 17 '20 at 15:37
  • Ah my apologies - but you don't state how; what differs from my example? Hardly a MWE, but one possibly explanation is that I compile to `.o` files, whereas you use Windows conventional `.obj`. Using `.o` is necessary in my situation – Anti Earth Apr 17 '20 at 16:10
  • I don't think the suffix was a problem. I just changed a single line in my makefile (https://github.com/fangq/mcx/blob/master/src/Makefile#L75) from .obj to .o, I was able to compile/link properly on my windows machine (win10, vc12, cuda 8), the only difference is the linker emits a warning `cl : Command line warning D9024 : unrecognized source file type 'mcx_core.o', object file assumed` , same warning like you saw. but but the binary was created properly. – FangQ Apr 17 '20 at 16:23
  • alright, re-reading your original post - was your question why linking command was sent to cl? you can find out by adding -v to the last nvcc linking command. From my test, it calls `nvlink` with `-link` to link, but has this line: `cl.exe @"C:\...\tmp/tmpxft_00...-8.res" -Fe"../bin/mcx"` at the end which emits the warnings. – FangQ Apr 17 '20 at 16:38
  • My question is " How can I force `nvcc` to just link the objects, and not incorrectly pass them to `cl`?" – Anti Earth Apr 17 '20 at 22:36
  • then you have to run `nvcc` with `-v` and understand what it does by calling `cl.exe -Fe` in the linking stage. – FangQ Apr 17 '20 at 22:41