I m writing a multimedia application .For Debugging purpose I need gstreamer debug builds for windows. Ossbuild only provides the release dll. Does anyone know where I can get debug dlls for gstreamer?
You'll have to build it yourself, until the Gstreamer SDK comes out for Windows. Even if you managed to obtain debug DLLs, they would have to be from the same version of gstreamer that you're targeting with your release build, or else you'd get non-meaningful results when debugging.
If you used OSSBuild with Visual Studio, you may be able to find the .pdb files for debugging already in $OSSBUILD/Build/Windows/Win32/Release/pdb directory; if you can find these files, you can add them to Visual Studio so it knows to use them by following, e.g. these instructions.
Reference for OSSBuild debug info: here
Related
I am building a Qt App but I am having problems when I move the app to another PC. When I run the .exe the it keeps saying it is missing dependencies and once I transfer the missing one another one pops up. I assume that I need to install something on the target pc that contains all of these DLLs.
Some of the missing dependencies so far:
MSVCP140D.dll
vcruntime140d.dll
api-ms-win-core-rtlsupport-l1-2-0.dll
I think that there may be issues with the install of MSVS or MSVC on my build pc as I constantly have to point to things like UCRT manually.
Thanks in advance
Missing Runtime: Those files are obviously part of a runtime that your application needs (Visual C++ Redistributable for Visual Studio 2015 - maybe?), but more than that you seem to have distributed the debug version of your application which will depend on debug versions of runtime dlls (dll name ends with "d" as in MSVCP140D.dll). These are generally only installed on developer PCs, and are not for distribution to client PCs at all.
Release Build: Maybe try to build your application in release mode and try to run that executable on your client systems. The required runtime might already be present on their boxes, just not in debug version.
Static Linking: I suppose you could also try static linking (for the Microsoft runtime: How do I make a fully statically linked .exe with Visual Studio Express 2005?), if that is available to you (I am not up to speed with Qt's handling of this in terms of availability of static linking with different forms of licensing): MSVCP140.dll missing. Just so it is mentioned: thought conceptually the same, static linking is different for Qt (licensing issues?) and the core Microsoft runtimes (see link above). Use a binary dependency checker to investigate how dependencies have changed with new compilation settings.
Remote Debugging: If you need to make a test PC capable of running your application in debug mode (maybe for remote debugging without installing all of Visual Studio): Preparing a Test Machine To Run a Debug Executable.
"Hacky": It seems here is another, "hackier" approach that I would not really recommend: install VC++ Debug Runtime Distributable. For other Visual Studio versions look for the debug_nonredist folder. Debug versions of an application are not redistributable, and debug versions of the Visual C++ library DLLs are not redistributable. Very important.
I am facing the following (fairly common) problem: I am running my program in Debug mode in VS2010 and/or VS2012, but at startup it crashes, saying:
The programme can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
Now I found a number of possible solutions, but none of them work for me:
Compile with /MTd instead of /MDd: actually this does solve the problem, but I am not allowed to: my program is part of a bigger program, and /MD[d] is mandatory.
Install the VS 2010 Redistributable package: This doesn't work because I have VS 2012 installed, so this installer tells me: "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
Finding, dragging and dropping a version of MSVCP100D.dll into the correct directory: I am not dropping unknown DLLs into places where they might interfere with other things.
Last resort: reinstalling VS2010/VS2012: possible, but as it would also mean reinstalling lots of other packages and plugins I need, I'd like to avoid this if it's not absolutely necessary.
Are there any other options left?
The Visual Studio REDIST packages never deploy the DEBUG versions of the CRT files. This is by design.
With VS 2012 or later, the easiest way to deploy the DEUBG versions of the CRT is to install the "Remote Debugging Tools" package on your test machines.
For VS 2012, the latest Remote Debugging Tools package is here
For VS 2013, the latest Remote Debugging Tools package is here.
Another option is to just use application local deployment of the DLL (i.e. copy it into your app directory). Again this is only for testing purposes. For actual deployment of your application, you are required to use the non-debug versions of the CRT.
If this error is happening on your development machine, however, then you have other problems because with VS 2012 installed, you should have the VS 2012 DEBUG CRT on that machine.
UPDATE:: Sorry, I would have expected the debug CRT DLLs to be included in the remote debugging tools package along with the remote debugger bits and the Direct3D 11 Debug Device. Alas, it's not. See Preparing a Test Machine To Run a Debug Executable. You have to either use the MSMs in Program Files (x86) directory in \Common Files\Merge Modules or copy the DLL-side-by-side from Program Files (x86) directory in \Microsoft Visual Studio <version>\VC\redist\Debug_NonRedist\. The VS Team probably assumed you would have already been doing that, but I'll suggest to them to roll it into the remote tools package.
I had a similar issue (the project made in VS 2012 but I was running VS2013) and resolved it by:
Open the project (or the solution ) in VS2013(or the newer one)
Open Project menu and select "Retarget the project" option (it was the first option but after applying it, this option vanished).
Rebuild your solution.
I am new to openCV and C++ and had the same problem using openCV 2.4.10 with Visual Studio Express 2013 on a Windows 7, 32-bit platform. If I made a simple program without using OpenCV, the program ran but when I used OpenCV I got the missing DLL error.
This post made things clear:
I guess the problem I had was not with my Visual Studio but my OpenCV. The OpenCV was compiled on a version of visual studio which required MSVCP110.dll. I could have tried another version of OpenCV or compiled OpenCV again using VS2013 but I was short of time. Instead, I found the dll file elsewhere and placed it in my system32 folder (not sure if that's recommended). This fixed the problem. However as #slater mentioned, I won't recommend downloading the dll from external website due to security issues.
This is a debug runtime DLL. If (and ONLY if!) you just want to run the debug build of your own application on a system without Visual Studio installed, then you can find the missing DLLs in
C:\Windows\System32 (for 64-bit builds)
C:\Windows\SysWOW64 (for 32-bit builds)
Just keep copying DLLs until your executable will run.
If this is NOT what you are trying to do, refer to https://stackoverflow.com/a/27386721/2279059, which is the CORRECT, but less practical answer.
I had the same problem, I found out that the cause is that I used dll compiled with VS2012 in a VS2013 project. JUST downloaded the missing dll and put it in my linker path and wala: the program worked. I downloaded it from http://www.dll-files.com/.
Particulars: My program was working in in release mode but not in the debug mode as it says the MSVCP110D.dll is missing. My code was an opencv image processing program. I put the missing dll in opencv linker path in the VS2013 project options.
Hey guys so I made a small program in visual c++ 2008 so that other people could use.
I sent the exe that was located in the debug folder of the project to my friends.
When they tried clicking it this is what they got:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
Does anyone know how I can fix this?
Maybe a build/compile option in Microsoft Visual Studios 2008/2010?
Or will they have to download something?
First step is to do a "Release" build. When you do a debug build your are linked to the Debug version of the CRT (C Runtime). Windows definitely does not come with the debug CRT (unless your friends install VS2008 also) and you are not allowed to redistribute the Debug CRT version.
Simply doing a release build may be enough. VS 2008 has been around long enough that your friends computers may already have the release version of the CRT.
If this does not work, point your friends to http://www.microsoft.com/en-us/download/details.aspx?id=29 so they can download and install the files they need.
And if that is not enough, you may need to keep track of which service pack of VS 2008 you built with because that may affect which version of the CRT they must download and install.
Anyways, good luck. Hope this helps.
We have a common compiled code library that is only accessible to a number of advanced developers within our company. We build releases for it periodically, releasing a 'release' version for our dev, test environments and a debug release for developers to use.
Oddly, when I build the Debug release, references to the path of my project on my PC show up when another developer tries to use the Debug version of the DLL on their PC. I haven't worked extensively with compiling these DLLs, but I should be able to build a Debug release and give it to other developers to use within their projects, correct? Or is that not how it works?
references to the path of my project on my PC show up when another developer tries to use the Debug version of the DLL on their PC. I haven't worked extensively with compiling these DLLs, but I should be able to build a Debug release and give it to other developers to use within their projects, correct? Or is that not how it works?
When you build a debug version, you're also building the .pdb, which contains the symbols required for debugging. This is going to include the file paths, line numbers, etc, and be based on the system where this library is built. That's why they see these paths.
That being said, this won't hurt anything - they can use the assemblies to debug, but won't be able to see the code itself when something happens, as they won't have the projects.
In my Visual Studio 2008 project, the active configuration is Release, and there are no debug symbols enabled in the Compiler and Linker settings. I'm building an exe file from command prompt:
devenv standalone_cpp.sln /build "RELEASE|WIN32"
There is no reason why a debug dll MSVCR90d.dll should get used at runtime, but it does and crashes. I don't have the slightest clue why only the debug dll gets picked up not the release dll MSVCR90.dll. Can someone please help?
I even tried building my .exe in debug mode hoping that it would not crash, but still it crashes with the same assertion failure _BLOCK_TYPE_IS_VALID(pHead->nBlockUse). Please help before I shoot myself.
Re-install the MSVS2008 Service Pack 1. Your install seems to have gotten corrupted.
I've had this happen -- it manifests with mysterious behavior like this, although I've also seen it manifest with strange "internal errors" when linking large DLLs/EXEs, and sometimes compiling very large projects, or very large translation units. For some reason, re-installing the service pack worked.
Here's a quick link: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en
Another thought might be that you did link debug into your release executable. Even though you built the solution for "RELEASE|WIN32", if any prerequisites (linked libs) were the debug version (either the *.lib was referenced directly, or you referenced the debug path instead of the release path), you'd end up with that mix and the "debug" version of that DLL would attempt to load.
Then, the reason it crashed, is probably that you allocated in a "release" module and deleted in a "debug" module (or vice versa). That won't work, because the allocators are different (since the "debug" versions allocate extra state for sentinels and other "debug checks").
Remember that MSVS2008 will "override" any project/solution settings with those found in Tools==>Options, even if you build from the command line. Check that no debug paths are set there for linking in your release targets. (That was a bad decision by Microsoft because it leads to project/solution files that do not describe what's actually happening, they removed that "feature" in MSVS2010.)
You might also have a look at:
Linking against library in release and .exe in debug crashes in Visual studio
C++ Linking release built library with my debug build
I think #Charley is on the money.
Download Dependency Walker and see what is actually causing the debug DLL to be loaded. If what you say in your question is correct, then it'll probably be another library that you exe is depending on.