Linking Errors after upgrading into CUDA 2.2 (Only Emulation)) Code is working fine using device mod

Hi All,

I have upgraded from CUDA V2.0 into CUDA 2.2. After the upgrade, I started getting linking errors in the emulation mode only. My code is working fine using device mode. I am using Visual Studio 2005.

I used the same exact path during the installation and checked that all environment variables are in place.

Your help is really appreciated,

–OA

[codebox]1>------ Build started: Project: PSO_GPU, Configuration: EmuDebug Win32 ------

1>Compiling…

1>sample.cu

1>sample.cu(478): warning: variable “selectedChannels” was declared but never referenced

1>sample.cu(481): warning: variable “path” was declared but never referenced

1>sample.cu(678): warning: function “scanf”

1>C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\stdio.h(295): here was declared “deprecated (“This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.”)”

1>sample.cu(696): warning: variable “_numberEnumPaths” was declared but never referenced

1>sample.cu(714): warning: variable “outtopologyIndex” was declared but never referenced

1>tmpxft_00000574_00000000-3_sample.cudafe1.c

1>tmpxft_00000574_00000000-7_sample.i

1>sample.cu(260) : warning C4244: ‘+=’ : conversion from ‘float’ to ‘int’, possible loss of data

1>Linking…

1>initialization.obj : warning LNK4075: ignoring ‘/EDITANDCONTINUE’ due to ‘/INCREMENTAL:NO’ specification

1>initialization.obj : error LNK2019: unresolved external symbol “double __cdecl calcBER(double,double,int)” (?calcBER@@YANNNH@Z) referenced in function “float __cdecl getAvailableBandwidth(int,int,int,float,float)” (?getAvailableBandwidth@@YAMHHHMM@Z)

1>sample.obj : error LNK2001: unresolved external symbol _connections

1>sample.obj : error LNK2001: unresolved external symbol _nodes

1>sample.obj : error LNK2001: unresolved external symbol _trx

1>sample.obj : error LNK2001: unresolved external symbol _S

1>sample.obj : error LNK2019: unresolved external symbol __Z11createSwarmfff referenced in function _main

1>sample.obj : error LNK2019: unresolved external symbol __Z14createTopologyv referenced in function _main

1>sample.obj : error LNK2019: unresolved external symbol __Z19printOutPutTopologyfi referenced in function __Z21printTopologyOnDevicei

1>sample.obj : error LNK2019: unresolved external symbol __Z21calcualteNumberOfhopsPi referenced in function __Z25printAllEnumPathsonDevicev

1>C:\Documents and Settings\osama.TRL\Desktop\May 10 2009 9_29 PM__PSO_GPU\EmuDebug\PSO_GPU.exe : fatal error LNK1120: 9 unresolved externals

1>Build log was saved at “file://c:\Documents and Settings\osama.TRL\Desktop\May 10 2009 9_29 PM__PSO_GPU\PSO_GPU\EmuDebug\BuildLog.htm”

1>PSO_GPU - 10 error(s), 7 warning(s)

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[/codebox]

Looks like you dont have the custom command line to compile your .cu file in Release mode (compare the settings to debug)

All those createSwarmff, createTopology,… are probably your functions that the linker doesnt find .

hope that helps

eyal

Thanks eyalhir74. Yes all these variables and functions I declare them externally in the .cu file

[codebox]extern Swarm * S;

extern Connection * connections;

extern Tranceiver * trx;

extern Node * nodes;[/codebox]

The problem that it’s not working in both emuDebug and emuRelease modes for the emulator, but it’s working fine using device mode (Debug and Release). I tried to uninstall CUDA 2.2 and reinstall CUDA 2.1 the one I was using before and it worked fine in both emulator and device. I would like to switch into CUDA 2.2 to take advantage of the new features including the Visual Profiler 2.2.

Thanks,

–OA

Whats the settings of the emuDebug/emuRelease for the cu file you’re trying to compile?

can you post the command line used in those configurations?

maybe you override/write to a bad place the obj file created for the cu file for those configurations.

It still seems to me like a misconfiguration in VS rather then some issue with 2.2

eyal

I am using the CUDA_VS2005_Wizard plugin to integrate CUDA with Visual studio. I am not sure if there is any conflict from the emulation properties in its custom rule that is causing this error. Please see attached(“cuda.rules.txt”:

cuda.rules.txt (5.25 KB)

)

Here is the command line:

[codebox]nvcc.exe -arch sm_11 -ccbin “C:\Program Files\Microsoft Visual Studio 8\VC\bin” -deviceemu -c -D_DEBUG -D_CONSOLE -Xcompiler "/EHsc /W3 /nologo /Wp64 /Od /Zi /RTC1 /MTd " -IC:\CUDA\include -IC:\NVIDIACorporation\NVIDIACUDASDK\common\inc -o EmuDebug\sample.obj sample.cu[/codebox]

Thanks again for your help,

–OA

The weird thing if I remove " -deviceemu" only from command line and I leave all other settings the same in the emuDebug I don’t get the linking error:

===
nvcc.exe -arch sm_11 -ccbin “C:\Program Files\Microsoft Visual Studio 8\VC\bin” -c -D_DEBUG -D_CONSOLE -Xcompiler “/EHsc /W3 /nologo /Wp64 /Od /Zi /RTC1 /MTd " -I"C:\CUDA\include” -I"C:\Program Files\NVIDIA Corporation\NVIDIA CUDA SDK\common\inc" -o EmuDebug\sample.obj sample.cu

Thanks,
–OA

I get the same linker problem, with CUDA 2.2 and only in emulation mode. I can link to the sample applications, but for my code that worked under a previous version of CUDA, the linker is unable to find any of the code generated by nvcc in emulation mode.

Also, I managed to get Windows 7 + VS 2008 Express + 64 bit compilation working, which was rather cumbersome, and this last emulation linker issue is all that remains in the way for me!

I’ll let you know if I manage to fix it :)…

  • Jarrad

I’ve got a fix, but it is a bit nasty:

Basically, you need to put extern “C” around everything in order for the linker to work in emulation mode under CUDA 2.2.

Is this an nvcc or Visual Studio bug?

  • Jarrad

That’s great :thumbup: Thanks Jarrad I will give it a try. I went back to CUDA 2.1 since I am very limited with time and I couldn’t afford spending too much time on this.

–OA

From the 2.2 release notes: “The default compilation mode for host code is now C++. To restore the old behavior, use the option --host-compilation=c”

Guess that helps :)

We’re not the only ones with this problem - see http://forums.nvidia.com/index.php?showtopic=96858 . It appears that nVidia is onto this as we speak :).