Force NV CC прямо к фазе связывания

Question

Я портирую приложение для графического процессора на Windows, используя MSV C, что не очень хорошо работает с NV CC. Я разделил фазы компиляции и компоновки. nvcc будет предварительно обрабатывать только файлы cuda:

nvcc -dc -ccbin cl somefile.cu

и cl скомпилируют все остальное:

cl anotherfile.c

Это разделение было необходимо, так как многие MSV C флаги (исключенные здесь) не срабатывают с переносом nvcc cl.exe (связанный признак здесь ).

После завершения компиляции я могу сделать два способа связывание.

1. используйте nvcc, чтобы связать только код устройства CUDA, а затем используйте link.exe, чтобы связать все, согласно этому руководству .

Как бы я ни старался, я не смог link найти заголовки CUDA, и я не смог найти ничего, что бы c указывало link на cudart библиотека. Если бы это было так просто, как их g++ пример!

позвольте nvcc выполнить всю связь.

В соответствии с do c, однако, "нет опции", чтобы перейти на стадию связывания. Поэтому, когда я пытаюсь все связать, используя ...

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

Я получаю некоторые предупреждения от 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

Естественно, nvcc предполагает, что эти объектные файлы являются исходными код и отправляет их на cl, потому что do c включает в себя:

Обратите внимание, что nv cc не делает никаких различий между объектами, библиотеками или файлами ресурсов.

Из Конечно cl жалуется - эти объектные файлы должны быть переданы непосредственно компоновщику. Я знаю, что link в конечном итоге вызывается, потому что я передаю ему некоторые несвязанные аргументы с -Xlinker. После этих предупреждений app.exe действительно компилируется.

Несмотря на то, что do c указывает на отсутствие аргумента фазы линкера, как я могу заставить nvcc просто связать объекты, и не неправильно их передать cl? Невозможно подавить эти предупреждения (по крайней мере, без того, чтобы был осужден сообществом stackoverflow).

Answer 1

посмотрите мой код cuda из http://github.com/fangq/mcx

, вы можете скомпилировать его на Windows в терминале Cygwin64 / MSYS2, от папки go до mcx/src и набрать " make ", это то, что я вижу

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

, он компилирует каждую c единицу и связывает файлы .obj как положено, я не вижу ничего плохого.