BrightBit
BrightBit

Reputation: 79

Missing MSVCR90D.dll

I'm writing a C++ program (32 bit) that uses SFML 1.6. The release build can be compiled and run without problems whereas the debug build also compiles without problems but can't be run. Dependency Walker shows that the debug version of SFML requires a MSVCR90D.dll and a MSVCP90D.dll. Both files can't be found on my hard drive. I didn't compile SFML myself (I've downloaded the binaries) and didn't notice before that it was compiled with Visual Studio 2008 whereas I am using VS 2010 Express. So I thought downloading the VS 2008 redistributables would fix the problem but it didn't. Now I am not sure if using libraries that were compiled with an older compiler version is a good idea in general.

Any suggestions on what I am doing wrong? Which redistributable do I need to install to get those missing DLLs?

PS: I am using Win7 64

Upvotes: 1

Views: 1450

Answers (2)

ceztko
ceztko

Reputation: 15207

For your main question, Rup is right. Regarding mixing VS2008/VS2010 runtime, let say that:

  • libA.dll is ABI (link time) dependent on VS2008 DLL runtime;
  • libB.dll is ABI dependent on VS2010 DLL runtime.

In my experience, it's safe in using release builds of both libA.dll and libB.dll in your VS projects as long as:

  • you are correctly dinamically linking libA and libB (selecting the correct libA.lib and libB.lib in the linker input);

  • using libA, libB headers doesn't create an ABI mismatch at run-time, depending on mixed VS2008/VS2010 headers (for example STL).

For example:

// libA.h

#include <vector>  

class LibAClass
{
private:
    // This is unsafe, warning c4251: users of libA may allocate a different size
    // than expected for the vector. The code can perfectly compile but at runtime
    // it can cause problems (verified myself)
    std::vector _list;

    // The following is safe as long as users of libA are not required to
    // deal directly with *_listp
    std::vector *_listp;
};

Upvotes: 1

Rup
Rup

Reputation: 34408

No, unfortunately those are the VS2008 debug runtime DLLs (the 'D' on the end). You're not officially allowed to distribute them.

Note that mixing C++ between compiler versions is dangerous. Your options are probably

  1. get hold of the source and rebuild it yourself with VS2010 (this will also allow you to debug into it which can be useful for understanding / discovering issues with the library)
  2. install VS2008 C++ (express or not) and work with that instead.

I was going to suggest getting the builder to re-build as release for you, but there's still the 2008 vs 2010 problem.

Upvotes: 2

Related Questions