I wrote a c++ program and converted it to a .exe file with the hopes to let it run on windows without needing to install a compiler. I ran well on my main computer (which has a compiler so it ran as expected) but did not run on another device. The error message shown was "libgcc_s_dw2-1.dll was not found"
How can I run a c++ program (or .exe file) from a flashdrive or other medium on any windows machine without extra installation.
C++ programs require additional c++ standard and runtime libraries to run. Most linker links to these libraries dynamically. That is some dll are required for running the program. You can run the program from a portable flash drive by copying those dll to the same folder as the application.
Alternatively, some linkers also have option to statically link, that is incorporate the code in dll ( kind of ) to your binary exe.
So you can either find out what all dll is required and copy them to your local folder ( maybe use something like dependancy walker or this newer one, i haven't actually used the newer alternative). Or use static linking like shown in this answer.
Related
Quick question here, okay say that I have downloaded additional libraries and added them to my version of visual studios and have their #include and commands in my project source code.
If I was to take the .cpp file and bring it to my school computer which also has visual studios and doesn't have these additional libraries, it would have a bunch of missing errors and can't compile.
but..
What if I publish my project and I have it in a .exe file and I was to try and run it on another computer that doesn't have these libraries? Would the executable file run okay?
When you
#include <stuff>
stuff is used during compilation time. However, the libraries it may refer to (e.g. the include gives the definition of many functions from an external library), can be
static or
dynamic
static libraries are linked statically when the program is built, and are part of the executable. dynamic libraries like DLL are linked during the execution of the program .exe. Thus they (DLL) may not be present on another computer when you run the same exe on it.
It depends on the libraries you are using, but sometimes a package is available for download and installation on the other computer, so that they become available. Sometimes you have to copy a bunch of DLLs along with your exe to the other computer. For instance, some advice from Microsoft in this regard.
I have a Visual Studio 12 project; source code written in C++; it's an OpenCV project. I want to give my compiled program to someone else, but, on other PC, I getting an error message about missing some dlls. My program using many OpenCV (maybe, not only) dll's. How can I resolve that problem? Maybe in VS 12 available an option to include all dll's in .exe?
It's a pretty similar question without proper answer:
include dlls in visual studio c++ 2008
DLLs themself can not be "statically linked" into an executable; that completely defies their purpose (well, actually you can use some really weird voodoo tricks to actually do it, but this is neither recommendable nor should you try it if you have to ask this question).
The simple solution would be to identify all the DLLs your program requires (just starting the program in the Debugger will generate a log file listing them all) and copy those DLLs into the same directory as the EXE resides in; as it happens the directory with the EXE file in is also the first directory where the system looks for DLLs before advancing to the standard system directories in default configuration. Package it up and distribute it that way.
the more complicated solution would be, to build static opencv libraries from src, then link your program against those, resulting in 1 large binary exe-chunk, that does not use any dlls (apart from ffmpeg, not sure about that one).
to build static libs, you'd need to run cmake with : BUILD_SHARED_LIBS=OFF
but take a deep breath, before doing that. linking your program will be sigificantly more difficult, because now you have to link all the zlib,libpng, whatever dependecies manually ( which before got conveniently linked into your dlls )
again, the most simple solution is to deploy all the opencv dlls with your program.
You can use the Windows Dependency Walker to determine which DLLs your program needs to run.
Actually, this only tells you which DLLs your program needs to launch successfully. If you load DLLs dynamically (via LoadLibrary) then you are on your own.
If you opt for the accepted solution (package the DLLs with the EXE file), and you don't want to go into the trouble of finding which DLLs to use, then you can copy all the OpenCV DLLs. They're not so big (65 MB on OpenCV 2.43). They are located at ...\opencvXXX\build\x64\vc10\bin\
where XXX is the OpenCV version. You can use x64 or x86 depending on your platform (32 or 64-bit). And the version of vc can be different on your system (vc9, vc10, etc...)
Well, trying to build a simple exe in visual studio 2012, with c++ win32 console app, just with a
printf("-----");
After build the release version, its running ok.
When transfer to another windows 7 clean installation, at running i get notice that the MSVCP110.DLL is missing...
Its not a native app ??? why extern dll is needed ?
In old win95 I make many executables with visual C 6 and its run standalone withou any dll.
I will always deplay this dll's with the "native" exe ?
When you write a C++ program, you use a few low-level libraries to interface with the machine. The C++ Standard Library is one example. Consider for example, new. When you call new in your program, you're invoking a piece of code that implements that functionality. Where is that actual code?
It's in a library. That library is deployed in a few different ways. One way is through dynamic linking, where the library is in the form of a DLL that needs to be present on the machine where you run your program. That's what MSVCP110.DLL is -- it's one of the library files your program was compiled against. Another way is to use static linking, where the code from that library is compiled directly in to your program. This results in a signifigant increase in the size of your application, but the other side of that coin is you don't need those library files to be on your target machine. You also need to make sure that other libraries your program use are also built against the same static library. If your program shares data with other programs, you further may need to ensure that those programs use the same static libraries.
Microsoft and Windows aren't unique in this. The same thing happens under Linux, albeit the libraries have different names.
There are pros and cons to using either shared libraries (eg dynamic linking) or static libraries. It's simple and catchy to say "gahrrr I hate shared libraries" but unless you understand why either is appropriate in what situation you stand to deploy a poorly-designed program.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
You cannot code a program in C++ that would work on any computer without giving your source code to be compiled.
For example, you could perhaps code in C++ a program, and compile it and build an executable which works on Windows x86-64, but that executable won't work on Linux (or MacOSX), and it won't work on ARM (e.g. Android phones) unless you consider using emulators
If you are developing your code with Visual C++ you may need to consider two options:
Make sure you link all libraries statically.
Install on the target computers along with your program Microsoft Visual C++ Redistributable Package corresponding to the Visual C++ version you use like the one at http://www.microsoft.com/download/en/details.aspx?id=5555. Some installer generating software will make it for you automatically.
Normally you would link your object file with some sort of a platform dependent loader. This loader loads your object and does all the stuff to start it from memory. Normally you can tell your compiler to link your object file and compile a blob. OpenGL is a powerful API and is usually distributed as a.dynamic linked library and is linked at runtime to your program. If I remember you just have to make sure the dll is where you want it and load the dll in your program from start.
Your C++ program is compiled and linked into an executable before it is run. You should be able to find that executable in a Debug or Release subfolder of the folder containing your project.
OpenGL, if you're not using GLUT or similar libraries, should just come with Windows and pose no additional problems. If you do use GLUT, it's enough to bundle the .dll file with your application.
In any case, the source code won't be necessary.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
By compiling and linking it into an executable. As long as you're not using some interpreted language (like Python, Ruby or such) you're presented with an executable inevitably. The biggest problem you may/will run into is dependencies on libraries. However those are linked into a binary as well. So what you're going to ship will be just a .exe; and some .dll maybe. Usually you'd wrap this in a installer package for deployment to the end user. Installers are created with something like the "NullSoft Installer System" (NSIS).
OpenGL itself is just a API, provided by a system library. So you don't ship OpenGL with your program, but expect the user to have it installed on the system (which will be the case if he installed the graphics drivers).
I'm doing a very small windows application consisting of just a single executable. As the program will reside on a SD card I want the application to be as self contained as possible, and I'd rather not have an installer. I'd want the user to be able to simply copy the executable to the SD card and be able to run it straight away without fiddling with anything extra. The problem then becomes the fact that my program is compiled with VS 2008 which requires versions of the CRT which I can't guarantee is installed. I'm linking statically to the CRT, which I incorrectly thought would circumvent this problem. I've been thinking of tracking down some older VS version, but I have a feeling this is the incorrect path. I want the program to run on a fresh install of windows xp and above.
Grateful for any help.
Linking statically to the CRT using /MT or /MTd (for debug) should do exactly what you need.
The fact that it isn't suggest that there is still something that depends on the dynamic library. That would be the case if you has some additional DLLs which are not compiled with the static CRT.
you can use the dependency walker (depends.exe) to figure out exactly which dlls use which and who still depends on the dynamic CRT or in any other DLL.
Another approach is to run your exe from the debugger and see which DLLs are being loaded in the output window. Which depends.exe gives you only the dlls loaded on the startup, this can give you some additional dependencies that are loaded only on runtime.
If you want the link against the DLL version of the CRT libraries and you want to avoid installing anything then you need to copy every member of the CRT assembly into the same folder as your executable. It may not be the way that Microsoft pushes you towards but it is valid and it does work.
In your Visual Studio 2008 install directory your should find a folder: VC\redist\x86\Microsoft.VC90.CRT. If you copy the complete contents of that folder (including the manifest file) to the same directory as your executable then you should be able to run the executable from that location.