0

I am new to C++ an I am making an application in Visual Studio 2010 using an SDK which has 3rd party dll's. I want to be able to run this program on other computers so I looked at this question to make sure I include them right (specifically Laserallan's answer). I then build the program in release mode and it compiles fine. The problem is, when I try to run the .exe in the sample release folder the program doesn't run. Not sure if these detals are relevent but my project uses MFC in a static library and Multi-Threaded(MT) runtime library. Incremental linking is not enabled.

My suspicion is that it has something to do with the dll's being in the same place as the .exe because if I move one of them out of the sample release folder, I get this error:

enter image description here

I also noticed this in the SDK's API. I'm not sure if it is relevent or not:

"The eBUS SDK is provided as DLLs. Static libraries are not offered at this point. Even though DLLs are provided, it is still necessary to link your application against link libraries of the DLLs."

The .exe was working fine before, It only started mucking up when I tried to put the dll's in the same place as the exe, tried to make it work on other computers and when I reinstalled the SDK. Does anyone have any ideas on what it could be? It has been doing my head in for the past 2 days now. Any help would be greatly appreciated.

Community
  • 1
  • 1
oodan123
  • 459
  • 2
  • 8
  • 23
  • 1
    Do you know if the SDK tries to pass CRT types over the DLL boundary? If so, you'll need to dynamically link to MFC and the CRT. – Billy ONeal Aug 12 '15 at 03:16
  • sorry I'm not very adept with programming yet could you elaborate a bit? How do I dynamically link to MFC and CRT? – oodan123 Aug 12 '15 at 03:33
  • @BillyONeal Also when I delete the dll's from the same place as the .exe the program runs fine. But that's not very helpful if I need to transfer the dll's to another computer in order for the program to run – oodan123 Aug 12 '15 at 03:35
  • Basically, every DLL needs to be built with the same compiler and C runtime libraries if you want to pass CRT objects across the DLL boundary. It looks like the DLL you depend on was compiled against a different version of MFC or with a different compiler than the one you're using. (I'm guessing) – Billy ONeal Aug 12 '15 at 03:44
  • One way to assess the types traded by your 3rd party DLLs is to inspect the header files. If there are MFC or other non-primitive types used, you will have to exactly match the build environment (and probably never use that 3rd party again as that is bad design). One way to assess the libraries (DLLs), those 3rd party DLLs depend on is to use ``dumpbin /IMPORTS ``. – BitTickler Aug 12 '15 at 04:07

1 Answers1

0

I solved it, turns out the new computer had 2 versions of PvBuffer, one had the GetAcquiredSize method and the other didn't. The program was executing the version that didn't and was trying to find a method that wasn't there. Thanks for your help!

oodan123
  • 459
  • 2
  • 8
  • 23