I have written a simple program in C++ that uses the boost filesystem library to organize some files. I am using the Visual Studio 2013 Express for Windows Desktop IDE. I would like my program to run on other computers without an installer or anything else. The user should be able to just download the program and click on it.
I built my program in Release mode and it works on my computer. When I tried to deploy on another computer, the error I got was MSVCP120.dll is missing. To fix this I right-clicked on my project, clicked properties, then Configuration Properties > C/C++ > Code Generation, and I changed the Runtime Library from Multi-threaded DLL (/MD) to Multi-threaded (/MT). Now my program won't compile properly because of this build error:
Error 1 error LNK1104: cannot open file
'libboost_filesystem-vc120-mt-s-1_55.lib' C:\Users\inspection\Desktop\sortFile\Project1\Project1\LINK Project1
I looked in the following folder:
C:\Program Files\boost\boost_1_55_0\libs\filesystem\build\msvc-12.0\release\link-static\threading-multi
and I could not find libboost_filesystem-vc120-mt-s-1_55.lib, though I could find libboost_filesystem-vc120-mt-1_55.lib. The file names are close, they only differ by an '-s' term located after the '-mt' term.
How can I statically link the boost filesystem library so that my whole program runs as a standalone executable, without another user having to install anything?
Boost needs to be recompiled to match your new runtime library setting. The filename of the Boost library indicates the settings it was linked with, and the Boost auto-link code automatically updated the needed filename to match your new settings. In this case, it quite accurately indicates that you need a Boost lib which was compiled with a static stdlib link.
Related
I have a project that I build with CMake, which is composed of a library black.dll and an executable black.exe that depends on the DLL. The DLL in turn depends on libz3.dll which is an external dependency.
When I build from the command prompt using CMake I cannot run the executable because of the error "The application was unable to start correctly (0xc0000142)". The external dependency libz3.dll is correctly copied into the executable directory.
But, when I build the project from Visual Studio 2019 (making it use CMake under the hood as well), everything works properly (when I copy libz3.dll into the executable directory).
I've looked at the two executables with Dependency Walker to understand what's the different between the two but there are no differences (both show errors of missing strange libraries such as API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL but in the case of the executable built with VS it seems to not be a problem).
I've also checked to be building for the correct architecture: both the executable, the library and libz3.dll are built for x64.
What can I check to understand what's going on?
So I recently finished a VC++ console application I have been working on and I sent it to one of my friends to try out but he cant even open it because he keeps getting an error.
A box will open up with the title Bad - Image and then it shows the error and stuff, it says it cant find the file MSVCP140D.dll on my friends computer but when I start the program it runs fine.
Can anyone tell me why he cant play the program and how to fix it?
You have built your project in debug mode and you are using Multi-threaded Debug DLL (/MDd) RunTime library.
In Visual Studio main menu, select Project -> Properties
Go to "Configuration Properties" -> C/C++ -> Code Generation
In Runtime Library, select Multi-threaded Debug (/MTd) and rebuild your project.
Alternatively you can build your project in Release mode, then select Multi-threaded (/MT) Runtime library.
This will make a stand-alone executable file which uses standard windows libraries, you won't have to provide additional dlls with the *.exe file.
You need to ship your program with the Microsoft Visual C++ Redistributable package. That's MSVCP140D.dll.
As user4581301 pointed out, the D in MSVCP140D.dll means 'Debug'.
You shouldn't ship a debug-enabled executable. It makes reverse engineering, hacking, and other modifications easier.
You should instead compile a release build, and ship it with the redistributable.
Well you need to do one thing(the easy solution), you just go to your system32 directory at system where you have built the code and find out the file MSVCP140D.dll, put it with your executable(.exe) and give it to your friend, and tell him to keep the dll in same folder as the exe.
MSVCP140D.dll (redistributable pack) is one of the run time dependencies you need to provide to run your application.
Now it will get installed. Or you can copy the dll at system32 at target system and then try.
But you shouldn't provide the debug build if you are giving it to client, you should provide the release version of it.
I've recently decided to try out PostgreSQL as the database platform for some C++ development I'm working on. I decided to use libpqxx as the connection library for my project, and quickly found out this would be an uphill battle to do from VS 2015 on a Windows 10 machine.
After much teeth-gnashing and nail-biting, I have gotten libpqxx to compile on Windows 10.
This leaves me with the following directory structure
Per libpqxx's documentation, I also placed a copy of libpq.dll in my project's executable directory. Please note: I have done this for both debug and release builds, tried to build both, and ended up with the same result.
All the tutorials I've seen seem to indicate that the library can be used after linking it and simply #including pqxx/pqxx, so I set up a small project to do just that. I receive the error:
fatal error C1083: Cannot open include file: 'pqxx/pqxx': No such file or directory
When attempting to build the project. I have also tried this will both debug and release builds, to no avail.
Here is a screenshot of my linker settings.
Does anyone have any suggestions for how I might be able to link and use this library from Visual Studio 2015?
As Sami Kuhmonen pointed out, this was not actually a linker error, but a compiler error. I needed to include an actual header, which Visual Studio needed to be able to find. After adding the correct folder (C:\libpqxx\include in my case) to Visual Studio's "additional include directories" setting under C\C++ -> General per drescherjm's suggestion, the program compiles just fine.
For future reference:
I did also run into unresolved external linker errors after solving the initial issue. This is because you need to make sure to also link to ws2_32.lib and libpq.lib. You also need to copy some other DLL files that libpq also relies on into your libpqxx lib folder. On my system, I believe these were ssleay32.dll, libeay32.dll, and libintl-8.dll. These files reside under the root of the PostgreSQL install. The DLL step is mentioned under libpqxx's INSTALL.txt file, however I believe it stated that the DLLs resided one folder under where I actually found them.
I have also faced same issue. Then I realized that I was building ,my application as a 32bit. I changed the target to x64 and it compiled successfully
When I make a simple program Whether Console or win32 When I copy the program to other pc or other os give me an error message, must have specific dll or lib files to the program works .
Example:
I created a simple console program and when it runs on other Windows or other pc asked me files (msvcp100d.dll, msvcr100d.dll) needed to the program works .
My question:
How can I run the program on any pc or Windows without it asks any file link, or even file libraries, or other.
Note: I'm using visual studio 2010 express edition with windows 7.
That is not always a good idea, and with some libraries you may have licensing issues, but you can link everything statically, instead of dynamically.
For example, for the MS C/C++ runtime libraries (msvcp100d.dll, msvcr100d.dll), you could change the settings in the Visual Studio. Open the project properties, and go to:
Configuration properties -> C/C++
change the 'Runtime library' to:
Multi-threaded Debug (/MTd) // for a Debug build, and to
Multi-threaded (/MT) // for a Release build
then, just rebuild your project, and it won't ask for those libraries again.
As for 3rd party libraries, you'll have to have a static build of the libraries (only .lib files, as opposed to lib/dll pairs which are dynamic). Furthermore, the static libraries will have to be themselves linked statically to msvcp100d.dll and msvcr100d.dll.
Once all those conditions are satisfied, you just link with those lib files, and your executable won't ask for dlls.
I have created a wn32 project with Visual Studio 2008 and Visual C++ language, it uses the ws2_32.lib library and then I compiled in Release mode.
It runs very good in the same computer, but when I copy the exe file to other computer (that doesn't have installed Visual Studio), it doesn't run.
The message I see is:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
But, if I compile my application using DEV C++, it generates a bigger executable (738KB) compared with the Visual Studio 2008 executable (9.5 KB). However, the DEV C++ executable runs in the other computer.
I have add the library ws2_32.lib to the linker properties of my project, in the Additional Dependencies field.
How can I fix it to work with Visual Studio 2008?
My code is the following: http://www.stan.com.mx/yupi/udpserver.cpp
The problem is almost certainly that the other computer does not have version 9 of the C++ CRT installed.
The default setting for compiling against the CRT in VS2008 is to dynamically link vs. statically linking. If you want to deploy your program with a real setup project you'll need to include the CRT redistributable.
However if you want to do an XCOPY deployment follow the steps on the following page.
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Try installing the Visual C++ redistributables. If that doesn't work, use DependencyWalker to find out what DLLs are missing.
I agree with JaredPar. The application you build with VS2008 is using dynamic linking, whereas the DEV C++ is linking statically, hence the larger size and why one works and not the other.
However, if its a plain win32 application project you've got (and you don't want/need to distribute it with a setup), you may be able to get it to run on another machine without redistributing the CRT by getting VS2008 to link statically for you (if its just the standard lib you're missing). I don't have a copy of VS2008 to hand, so I'll describe how to do it in VS2005 and hopefully it'll translate across.
Bring up configuration properties for the project (right click the project name, then select "properties" from the menu)
Expand "Configuration Properties", then "C/C++", then click "Code Generation"
Under the "Runtime Library" item, for your particular configuration select the non-DLL version of the library i.e. for debug builds you want "Multi-threaded Debug (/MTd) and for release builds you want "Multi-threaded (/MT)"
Try and see if that works. You'll obviously get a much bigger final binary now the library is statically linked.
You may be missing an external dependency required by your program. Check the project settings to see if you are linking against MFC dynamically for example. You can also run Depends utility to check for missing dependencies.