Wednesday, August 29, 2007

Linking to C++/CLI Static Libraries

So I had this weird problem where I was building a C++/CLI static library that included managed and unmanaged code. I had an unmanaged class that called static functions from a managed class (this is known as mixed mode) and was compiling the whole thing with /clr. When I was building another mixed mode .dll that called the mixed static library, I was getting linker errors to the functions in the static lib's managed classes. I found this on microsoft.public.dotnet.general newsgroup:


Hi all,

I have a .NET solution with several projects in it. One project is a "utilities" project that is compiled into a static library. It contains managed and unmanaged C++ in several files. So I am compiling using managed extensions. This project compiles successfully.

Another project in the solution, BrassControls, is dependent on the Utilities project. It uses several of the classes in Utilities. However, it fails at linking. I get the following error when building the BrassControls project [ -- the class BrassVersion is in the Utilities project]:

LINK : error LNK2020: unresolved token (06000050) Brass.BrassVersion::.ctor
LINK : error LNK2020: unresolved token (06000051) Brass.BrassVersion::.ctor
LINK : error LNK2020: unresolved token (06000052) Brass.BrassVersion::Finalize
LINK : error LNK2020: unresolved token (06000053) Brass.BrassVersion::ToString

These relate to the functions in the Brass::BrassVersion class. This is the only class in the Utilities project that is a __gc class.

I have verified that the project dependencies are set so that BrassControls is dependent on Utilities. But for some reason it can't "see" the tokens associated with BrassVersion.

Both projects are compiled using managed extensions. Both are using the same run-time library.

Can anyone help me figure this out?
Thanks,
Matt.


Ah-ha! This was exactly my problem. Unfortunately, the newsgroup didn't have an answer and it took me a few more hours to find it. The answer is easy... on the .dll that includes the static library, make sure the Linker option for the .dll "Use Dependency Inputs" is set to "Yes". I guess for unmanaged classes it would include them, but for managed classes it wouldn't, so I was getting a linker error (LNK2020) for unresolved tokens. It took me forever to figure this out and really pissed me off. I found the answer here.

Tuesday, August 14, 2007

Making C#, C++/CLI, and C++ play nicely together

One of my favorite pastimes is to get different computer languages to interoperate. Can't we all just get along?

So one thing I wanted to do was use C# windows forms (and other stuff) with C++ code. The first thing I needed to find out was how to debug such a monstrosity in Visual Studio. Here's how you set up your project to step from C# into C++ land seamlessly:
Debugging in Visual Studio .NET

So the other weird thing I ran into was linker errors. I was trying to reference a mixed code .dll (compiled with /clr) from another native code .dll. Doing Properties->Linker->Input->Additional Dependencies for the project and adding the .dll causes a linker error: LNK1302. Apparently you have two options: compile the .dll with /clr:safe OR include every stupid .obj file for every .cpp file that you have in the .dll you want to include. Another option that I found was to give up on the .dll thing, and just make a statically linked library (change the configuration to produce a .lib instead) for the mixed-code library and then include this in the other native code .dll. Then, I can include the Additional Dependency without difficulty. My project compiles and works as expected for now, though I read somewhere you can get weird initialization problems sometimes when you have mixed-mode libraries. I'll be on the lookout for that gotcha, but for now using .lib's seems to work for me.

In summary, I have C#->C++/CLI .dll -> C++ & C++/CLI .lib
I say C++ & C++/CLI .lib because in some .cpp files I use .NET types (declared as a public ref class), and in others I do not (these are declared as public class).

C++/CLI is very weird... it's sort of like a computer version of Esperanto.

Anyway, this pdf file has some useful general info on C++/CLI etc:
link It's from a book, Expert C++/CLI

Tuesday, August 7, 2007

Link Port booting the TigerSharc with the EZ-Lite Kit

So, I was using the example that came with VisualDSP++ to do link port booting of one TigerSharc processor on the EZ-Lite Kit eval board using the other one. (Found in C:\Program Files\Analog Devices\VisualDSP 4.5\TS\Examples\ADSP-TS201 EZ-Kit Lite\Link Boot.) I was able to run the Master code (which DMA transfers the user code to the 2nd processor) and initialize the memory in the 2nd processor, however the code didn't work (i.e., I got no output).

Turns out that the boot loader in the example (TS201_link.asm) is out of date, and you have to copy the new one (in C:\Program Files\Analog Devices\VisualDSP 4.5\TS\ldr\TS201_link\TS201_link.asm) to the example directory, change the "#define LINK 3" to "#define LINK 2" (since link port 2 is joined between the 2 processors), and recompile the boot loader. Then, you can follow the readme and actually get the IIR code to work.

Analog drives me nuts with this crap.... their examples seem to be out of date a lot of the time.