Properly Exporting Programs

[Robonics]

I have been writing C++ for about 3 months now and I want to export my projects to another computer, however every time I do, the program is missing .dll files. After doing lots of research I came to the conclusion that I need to build a "Release Build" However, all of the articles I found are out of date and do not pertain to the latest version of my IDE or compiler

IDE is Visual Studio and Compiler is MinGW-w64

[Ganado]

Hi again, if you're using the same version I used in the last thread, apparently it doesn't link libgcc statically by default. If you link dynamically, you'll need to provide the DLLs that it asks for and put them in the same folder as your .exe when you give it to another person. (The DLLs are most likely in your mingw bin folder, or somewhere around there).

However, to avoid this, you can also statically link libgcc.
You may need to add these three flags to the beginning of g++:

-static -static-libgcc -static-libstdc++

Apparently there are some potential pitfalls with statically linking, though I'm not very knowledgeable of the details, see: https://stackoverflow.com/questions/18138635/mingw-exe-requires-a-few-gcc-dlls-regardless-of-the-code

(If you already use Visual Studio, it is probably easier to just build using VS's C++ compiler, but up to you)

[Nico]

MinGW-w64 compiles your program with the assumption that you are going to use it on a computer where (I believe three) specific DLL's are available. By making this assumption they can create a smaller executable, which saves you disk space if you have many programs on your system.
Other compilers may have chosen differently. The TDM compiler for example creates an executable that can run without any DLL's. This is possible because they included the code that is in the DLL's in the executable. As a result the executables they generate will be larger files.

For distribution of a program that has been compiled with the MinGW-w64 compiler, you have to distribute 4 files (the executable and the DLL's it requires to run). The DLL's are available in the MinGW-w64 folder and can just be copied to the other computer.

If you place the executable and the DLL's in the same folder on the target machine, your program should work.

[Robonics]

Thanks for the answer, the exe exported and ran by itself with no other installations required.

[George P]

With Visual Studio 2015-2019 there are two options for generating C/C++ code into an executable:

1. Generating code that uses the VS release run-time C/C++ libraries, reducing the size of the .exe.

2. Generating code that links all the run-time code needed into the .exe, bulking up the final file size.

There are x86/x64 VS redistributables that add the VS release run-time libraries onto a target machine so apps don't need to link all the run-time code.

VS 2017 redistributables seem to be only for VS 2017 C/C++ apps, VS 2019 redistributables are usable by 2015/2017/2019 created C/C++ apps.

[jonnin]

adding to the above ... visual studio provided debug versions of libraries. You can copy them over to a target machine, but the correct thing to do is compile as release mode. When you do this, the dll will change to the normal one and the program will work if the dll is on the target machine; it probably will be if you have the standard vs redist package installed. This issue is easy to spot, it will ask for a common dll with a D on it, eg MSVCsomethingD.dll such as MSVCRTD.dll

I don't know if you will run into this using an alternate back end compiler.

[George P]

@jonin, the debug run-time libraries are not legally allowed to be redistributed to other machines that don't have VS installed, only the release run-time libraries.

[jonnin]

Didn't know that. Over-regulation much? Its mostly not a good idea anyway, you will spend a while copying things you didn't need just to force the wrong compiled exe to run, better to click release...

[George P]

MS has wrapped up the release run-time libraries into a "simple" container. One for x86 apps and the other for x64 apps.

The install executables can be found deep down in multiple folders where Visual Studio was installed. On my main programming machine it is

D:\Programming\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.24.28127

2017 uses the same folder structure.

D:\Programming\Microsoft Visual Studio\2017\Community\VC\Redist\MSVC\14.16.27012

The debug run-time libraries are "loose."

The speed of a debug compiled app is atrocious, the size is bloated as well. Not using the debug run-time libraries really bulks up the bloat.

I'd never distribute a debug compiled app, even for testing purposes, to a machine that doesn't have the same version of VS installed.

[jonnin]

I'd never distribute a debug compiled app, even for testing purposes, to a machine that doesn't have the same version of VS installed.

when I did this, it was an extremely limited embedded box, lacking ram, disk space, and horsepower to run vs. I agree, its an oddball thing to do. You can remote debug it, and the specialized hardware needed to run it is on the target box...

[George P]

Thanks to Duthomhas, or was it JLBorges, I found it is possible to download the VS compiler without all the overkill of the IDE. For command line compiling.

I haven't installed the Build Tools for Visual Studio, but not including the debug and release run-time libraries would be a dumb idea.

https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019