analog feelings, digital world

It is kind of a strange, but it is not so simple as you may think. There is a sample project in CUDA SDK, and it works, but… it is strange that if you exclude all .cu and .cpp files and add yours… surprisingly it stops working. Why? There were some problems while linking: I got messages that there are bunch of symbols already defined elsewhere. Well… in this case it is because of LIBCMTD (but read further please, it is not always the problem with LIBCMTD) – default library that is being linked by VS. How to overcome this problem? There are two solutions:

• you may add “/FORCE:MULTIPLE” in linker options (Project properties –> Linker –> Command Line) – but this does work… partially – it creates proper executable, but in my case I got some assert exception at the very end of executing my app (actually it was when all resources were to be freed – but I didn’t want to investigate it further – app worked, but it is strange to see the exception dialog all the time)
• you may exclude one of the libraries that is causing the problem. Which library? Well, it depends on: what was your project type (Linker –> System –> Subsystem: /SUBSYSTEM:CONSOLE, /SUBSYSTEM:WINDOWS…). In the sample form CUDA SDK, the library that you should get rid of (Linker –> Input –> Ignore Specific Library; remember to write only library’s name, without extension) is: LIBCMTD, in my own project (created from scratch) it is: MSVCRTD for Debug, and LIBCMT for Release. The only advise is to look carefully at what is your linker spitting out, and just ignoring this specific library that makes the whole process to fail (and it is very good idea to have more verbose output: Linker –> General –> Show Progress: /VERBOSE:LIB or even /VERBOSE). In my case the BuildLog.htm (automatically produced by VS) contained following information:

[...]

MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)

[...]

Finished searching libraries LINK : warning LNK4098: defaultlib ‘MSVCRTD’ conflicts with use of other libs; use /NODEFAULTLIB:library

[...]

As you see, the problem lies in linking MSVCRTD.lib. Although it is not always so easy. Sometimes different library should be excluded from the process of linking.

It seemed to me, that the problem was fixed. I was wrong. Something bothered me. Why there were no simple solution for this problem? And why the problem was not always with the library the linker had problem with (the one, that it informed about problems with)? And than I started thinking about something I read about how Microsoft C++ compiler / linker works: there are bunch of libraries that are included by default. The libraries are organized in groups (compiled with debug info for debug purposes, etc.), and compilation or linking and mixing libraries with two different worlds may lead to errors. If you right click on your .cu or .cpp file in your project and navigate to “General C++ –> Code Generation” (in case of .cpp file) or “CUDA Build Rule v.2.1.0 –> Hybrid CUDA/C++ Options” (in case of .cu file), you’ll see “Runtime Library” option. And if all your files share the same setting, the problem with linking disappears, and now I am sure, that this is the right solution :) And remember, that this option for all the files must be exactly the same! “Multi-Threaded” and “Multi-Threaded DLL” are NOT the same (the have different linker switches), so just be careful, and pay attention what you change.

I hope it helps someone, because I have wasted a bit of time.

Tags: c++, CUDA