views:

281

answers:

1

I've just gotten an application to compile and run by telling my VS 2008 project to ignore libc.lib in the linker->input section off the project properties menu. Before I did this VS gave me the old "fatal error LNK1104: cannot open file 'LIBC.lib'" message.

I'm not sure how this app compiles if I'm ignoring the crt, but that's obviously my ignorance speaking.

I checked the C/C++ project settings and the runtime library setting reads multithreaded debug dll (/MDd flag)-- so I must be linking to a VC80*.dll somewhere.

I'm not sure how though. I've always been confused about the crt settings in visual studio, static or debug, multithreaded or not. From reading this site and google I have a rough improvement in my understanding now-- if you use the dlls you don't have as much code bloat, things link when the program needs them, crt updates can be applied by overwriting the dll. The usual reasons for using a dll in other words.

But what's with the multi-vs-single threaded versions? If I happen to link with a static version I can't use win threads or pthreads, is that what that means?

One other thing which I've heard about but never quite followed-- there are problems in allocating an object in one dll and deallocating it from another, or something like that, to do with cross-allocation. I'm not explaining that well (because I don't understand it) but I hope you get my point and can explain what's going on there. Does it mean that in my program I can't call new ObjectX() on a class that lives in a dll? Can't mean that, can it?

Thanks everyone!

A: 

But what's with the multi-vs-single threaded versions? If I happen to link with a static version I can't use win threads or pthreads, is that what that means?

There is no (native) pthreads in Windows - so it's more Windows Threading, but that's the basic idea. However, VS 2008 doesn't support the single-threaded versions - they have been dropped, so if you're using VC++ 2008, you'll always use the multi-threaded VC++ runtime libraries.

One other thing which I've heard about but never quite followed-- there are problems in allocating an object in one dll and deallocating it from another, or something like that, to do with cross-allocation. I'm not explaining that well (because I don't understand it) but I hope you get my point and can explain what's going on there. Does it mean that in my program I can't call new ObjectX() on a class that lives in a dll? Can't mean that, can it?

This is more of an issue with allocating objects in a DLL which was compiled with a different VC++ runtime than the calling project. If you compile a DLL with VS2005, then try to do "new MyClass();" within a VC 2008 project, you can run into problems.

This is due to changes that are made between VC++ runtime versions. Different versions are free to manage memory allocations and deallocations in their own way. Trying to allocate or delete across a "runtime library" boundary tends to cause bad things to happen - quite often, you get crashes.

Reed Copsey
Thanks for the explanation. Does this mean that the dlls created by different versions of VC++ may be using different versions of the crt, and may therefore have slightly different implementations of malloc, free and delete? So if my program, built in VS2008, calls new() on your VS2005 version of MyClass, whose version of the crt is allocating the memory? And when I call delete(), which version destroys things?
larryq
That's the problem. If you want to make a reusable DLL, it's best to make C functions that handle the allocation and deletion of your classes. Instead of using new MyClass() and delete myClassInst, it's best to have a function that does MyClass inst = AllocateMyClass(), and DeleteMyClass(inst), so the runtime used for compilation handles the new/delete (or malloc/free).
Reed Copsey