I managed to compile VTK example (http://www.vtk.org/Wiki/VTK/Examples/Cxx/PolyData/Curvatures) in MSVS 2010 but when I tried to run it, it stopped. Does anyone know the cause? I can run other VTK examples successfully but not this one.
From the comments, the problem is caused by using Release .dlls in a Debug application. Remember that the Release heap is not compatible to the Debug heap. Which means any allocations in the Release heap can not be freed in the Debug heap or vise versa. As a result of this it is not generally safe to mix Debug and Release in the same application.
Now in the case of VTK (since I have used this on many machines and have built this 100s of times using Visual Studio over the last 5+ years) my recommendations are to turn off the building of shared libraries with vtk. And avoid the use the INSTALL target with for VTK, ITK, GDCM or any CMake based library that names its release libraries the same as its debug libraries. Instead use BUILD_ALL for all configurations you will need in your application. Then when you need to configure your application to use CMake I point VTK_DIR to the root directory of the folder where I built VTK and CMake will then correctly use the Debug libraries in my Debug application, Release libraries in my Release application..
Related
I have downloaded wxWidgets-3.1.0.zip and extracted it to D:\wxWidgets-3.1.0. MY OS: Windows 7 Professional 64 Bit. I am using visual Studio 2015.
I build the library through running: D:\wxWidgets-3.1.0\build\msw\wx_vc14.sln, It was OK. So I can build the projects in samples.
The thing that matters I cannot run this application on another machines where wxWidgets is not installed there. I Don't know Which dlls I must Copy side-by-side my application.
How Can I Also build statically my application so I don not have to copy Dlls?
Can any one add a useful tutorial step by step on how to build on both: Static and dynamic?.
If you open the D:\wxWidgets-3.1.0\samples\minimal\minimal.sln you will be able to see what options you should set. Also, by default, the solution is set to build statically build executable. You can also try to change the "C/C++ -> Code Generation -> RunTime library" in order to statically link the CRT.
If you still need/want the DLL build, at the very least you will need "base" and "core" libraries from D:\wxWidgets-3.1.0\lib\vc_dll folder. And you will also need the CRT libraries. Every time you run the binary, you will get an error on screen that "library such-and-such can't be found". Just copy the library to the same folder where the executable is located.
The other thing - you should've build the library with "Build->Batch Build...->Select All->Build".
HTH.
MSVS 2015 doesn't support linking CRT statically any longer, so you will need to install its CRT DLLs on the target machine in some way. It could be as simple as just copying the DLLs to your application folder (although this is not recommended by Microsoft), but it still needs to be done.
You can build wxWidgets statically simply by choosing the "Release" configuration in the solution file (and not the "DLL Release" one).
For a cross-platform software project that builds on Linux and Windows we have distinct ways to handle third-party libraries. On Linux we build and link against the versions distributed with the CentOS/RHEL distribution, which means we link against release builds, whereas on Windows we maintain our own third-party library "packages" and on Windows we build two versions of every library - a release version that links msvcr100 and msvcp100 and a debug version that links msvcr100d and msvcp100d.
My question is simply whether it is necessary to build the debug version of the third-party dependencies on Windows or can we simply use /nodefaultlib:msvcr100 when building debug builds of our own software.
A follow up question: Where can I learn about good practices in this regard. I've read the MSDN pages about the msvc runtime, but there is very little there in terms of recommendations.
EDIT:
Let me rephrase the question more concisely. With VS2010, what is the problem with using /nodefaultlib:msvcr100 to link an executable build with /MDd when linking with libraries that are compiled with /MD.
My motivation for this is to avoid to have to build both release and debug version of third party libraries that I use. Also I want my debug build to run faster.
From the document for /MD, /MT, /LD (Use Run-Time Library):
MD: Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib
/MDd: Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file.
So there is no documentation for any difference done to the generated code other than _DEBUG being defined.
You only use the Debug build of the CRT to debug your app. It contains lots of asserts to help you catch mistakes in your code. You never ship the debug build of your project, always the Release build. Nor can you, the license forbids shipping msvcr100d.dll. So building your project correctly automatically avoids the dependency on the debug version of the CRT.
The /nodefaultlib linker option was intended to allow linking your program with a custom CRT implementation. Quite rare but some programmers care a lot about building small programs and the standard CRT isn't exactly small.
Some programmers use the /nodefaultlib has a hack around a link problem. Induced when they link code that was built with Debug configuration settings with code built with Release configuration settings. Or link code that has incompatible CRT choices, /MD vs /MT. This can work, no guarantee, but of course only sweeps the real problem under the floor mat.
So no, it is not the proper choice, fixing the core problem should be your goal. Ensure that all your .obj and .lib files are built with the same compiler options and you won't have this problem. If that means that you have to pester a library owner for a proper build then pester first, hack around it only when you've discovered that you don't want to have a dependency on that .lib anymore but don't yet have the time to find an alternative.
If I built my app against D3DX June2007_d3dx9_34 and the target system has a newer version Nov2007_d3dx9_36 should that be a problem?
I distribute D3DX DLLs using MS' redist-installer tool but I noticed one one 'clean' PC (no D3DX previously installed) I got an error about missing D3DX DLL. Before trying to figure out if the installer itself is not working, I wondered if maybe supplying a too-new version of the DLL is the problem - will the app be looking for a DLL with the exact name?
D3DX libraries are not backwards-compatible, and the API may change between versions. So the target system must have the same version of D3DX that you build your application with - a newer version won't work.
If you use Dependency Walker on your application, it should show you that there's a dependency on a DLL with the exact version number.
The redistributable in the DirectX SDK includes the whole history of the D3DX dlls. Installing the latest version of the DirectX redistributable should have your system end up with every version of these dlls. It is possible and allowed for applications to only install the files they need by deleting cab files out of the redistributable's directory structure, in order to reduce the size of the redistributable components, and this is how you can end up with having 43 of the dll but not 37 for instance.
If you remove the dependency of D3DX and D3DCOMPILER dll's from your application you can ensure the application will work as the d3d9 d3d10 and d3d11 core dlls are version-agnostic and are also tied to the windows service pack releases (i.e. D3D11 for Vista comes from Vista SP2 or Win7 stock installs for example).
Another possible way to remove the dependency and let the app startup is to make the dll a delay load module, so it is only loaded when needed (such as compiling shaders on a development environment). As long as you are sure the shaders exist on end-user machines properly it won't need to compile shaders and won't crash. Calling LoadLibrary and invoking the functions manually would be a safer choice with a way better error message of your choosing, but is a lot more work.
i have developed application in visual c++ 6.0,i have do exe of that application,i have done by using icnt.exe(install creator),but when i run my application exe file on other system which does't have the vc++ software it's showing dll files are missing,how could than i downloaded the dll files again it is asking other dll's files.i want run my application without installing vc++ software in windows,how can i solve it,plz help me i'm touble.
How to make Realease build? by default its debug build
thanks for reply.
As a wild guess, you have deployed the Debug build, which depends on DLLs that are not allowed to be shipped.
If that is the case, have VC6 create a Release build and deploy that.
You can verify which DLLs are required by your application with the depends.exe utility that came with Visual Studio.
Edit: The easiest way to get a release build when ready is to use the Batch Build command from the Build menu. It will let you pick among all of the known build types in the project, and choose to either build them clean (recommended) or to just bring them up to date.
It is also possible to switch the GUI to default to the Release build instead of Debug. That is the right thing to do if you actually need to run the debugger on the Release build. Note that both builds include debug symbols. The differences have more to do with which runtime libraries are linked, and certain optimizations such as making the assert() macro have no effect.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.