I thought if you compile a Visual-studio 2013 Win32 project using /MT Code Generation->Runtime library then it will automatically package all dependency dll's - including 3rd party dll's - into the executable?
Currently certain users get an error when running my .exe. Its related to not having a 3rd party dll (OpenSSL):
The program can't start because LIBEAY32.dll is missing from your computer
This error has occurred for users using my .exe on Windows 10 OS's. How can I ensure all dependency dll's are packaged into my .exe?
I currently compile my application on my 64bit Windows 8.1 OS. The win32 visual-studio project is compiled using the following project properties:
Character Set: Unicode char set
Use of MFC: Use standard windows libraries
Whole Program Optimisation: Use Link Time Code Generation
Debug info format: none
Code Generation->Runtime library: /MT
/MT indicates that you are using multithread, static version of the run-time library. This doesn't affect third party dependency, e.g. OpenSSL is still linked dynamically.
To check your dll's dependency I prefer Dependency Walker tool. It will show if some of dependency is missed.
To ensure all dependency linked into your .exe file use static linking for all your third party dependency, e.g. for OpenSSL you should use libeay32MT.lib library.
Nikita is right, use Dependency Walker and I'd add that you're missing some knowledge about what a DLL really is. No offence meant, I know dlls can be a pita. What is a DLL?
By definition a DLL is not included in your .exe but it is loaded at runtime and could be shared amongst several applications. If you want to include it in your .exe it will require some extra non trivial work to embed them into your exe, unpack and load at runtime.
See this post
I'd suggest to use an installer instead, much easier to handle! Just create an installer (you know the click click click "yes-yes-I agree-Ok-Done" wizard installer) that will include your .exe and all needed dependency files. As a reference Inno setup is quite great.
Related
I've created a Static Library (no mfc is used in it) in Visual Studio and want to link with it in statically linked mfc project (com-dll actually).
When linking mfc-lib I get a bunch of messages symbol is already defined. This is because I linked standard C++ library twice (once in static library, and other in mfc project).
How do I fix it?
There is a workaround with /FORCE:MULTIPLE, but I think this is a bad decision.
When linking static libraries to a DLL or EXE project, you need to take care, that all projects have been compiled to use the same runtime library. So please set all projects to the same "Use of MFC" and also to the same "Runtime library". If you do not do so, then one project might have been compiled to take the fopen function from the standard CRT while another project might have been compiled to take the fopen function from the MFC. Mixing these is a problem for the linker because he does not know which runtime (and in the example: which fopen) to use.
When linking your DLL or EXE project against another DLL project, this is not a problem. You can have a DLL without MFC usage and link your MFC EXE against that DLL.
If you have a util library that you use very often in different projects, then you might consider setting up different build settings so you can build your library in DEBUG and RELEASE and with and without MFC. Then in your EXE project you can pick the library binary that matches your project settings.
When i use Visual Studio, my executables depends on microsoft redistributable package - the package that deploys MS's runtime DLLs. That is annoying to me. What disatwantages my executable would have if i would use MinGW?
I also want to try link with lib- avcodec/avformat, that are built by MinGW and i have no my own mind power to build them in VS from src.
In case of using MinGW you will depend on DLLs that are shipped with mingw. It is not big deal to change one vendor to another.
If you already have MS project, review possibility to statically link MS libraries (it is option is provided for some of VisualStudio projects on creation time in project options)
You can link everything statically with MinGW. Use the -static linker flag.
No need for redistributing any DLL's, but you have to make sure that in the c++, there's no exceptions being passed over DLL boundaries (so make sure every C++ library is linked statically in this case).
I have a managed C++ dll which uses a unmanaged C++ lib. I've added the lib file in the managed project's "Additional Dependencies". Unfortunately I get a dozen of std::locale already defined in msvcprtd.lib linking errors.
Any idea? Do I have to build both as dll and link them together?
You probably need to change the runtime library setting for one of your projects so that they are both the same. The "Multi-threaded Debug DLL" option in the runtime library settings means that your project will be linked against the DLL version of the runtime lirary, not that your project is a DLL. Where-as "Multi-Threaded Debug" means it will link against a .lib version of the standard library.
When you link together 2 projects that use different settings, then they end up with duplicate references. One reference from the static runtime library, and one from the DLL runtime library. This is the source of your errors.
Which setting you should pick depends on whether you want to distribute the runtime DLLs with your project (or count on the user already having them). If you want to go for this option, select the DLL runtime library, otherwise select the non-DLL version. The down side of the non-DLL version is that all the runtime library code will be embedded in your DLL/EXE, which will increase it's size.
EDIT: Actually, looking into it a bit more. This link indicates that with CLR projects (which I suspect yours is, being managed C++) you can't use the static linked option, so you need to use the "Multi-threaded Debug DLL" option for both.
I have a simple C++ program. I want to just build the exe and give it to a person on another complete non-development box. Is there a way to build such a simple, single-source file to an executable in Visual Studio without needing all the crap ? I have changed the program to compile in MT mode, instead of MTD which statically linked the msvcr.dll file, but now it is looking for msvcp.dll file. How can I compile so that my executable either 1) doesnt include all this junk or 2) statically links it all so that I have exactly one file to transfer to another Windows PC to run
Thanks
If compiling with /MT is requiring msvcr100.dll, something included in your application is probably trying to link with it, possibly a third party component. I would check any third party libraries and related.
MSVCP100.DLL is the C++ standard library. You might want to double check that it's not looking for MSVCP100D.DLL, which is the debug version; mixing release and debug mode libraries could cause this.
MSVCRT100.DLL is the C run-time library, and MSVCP100.DLL is the C++ standard library. Both should go away if you build with /MT, in that case static versions of these libraries should have been used.
My guess is that you either did not fully rebuild your app after switching to /MT, or that one or more files in your project have custom settings that include /MD. You may want to open the properties dialog box on the page that shows the /MT and then click on all your source files one by one to verify that none of them still show /MD.
I'm wondering how to make a release build that includes all necessary dll files into the .exe so the program can be run on a non-development machine without it having to install the microsoft redistributable on the target machine.
Without doing this you get the error message that the application configuration is not correct and to reinstall.
Choose Project -> Properties
Select Configuration -> General
In the box for how you should link MFC, choose to statically link it.
Choose Linker -> Input. Under Additional Dependencies, add any libraries you need your app to statically link in.
You need to set the run-time library (Under C/C++ -> Code Generation) for ALL projects to static linkage, which correlates to the following default building configurations:
Multithreaded Debug/Release
Singlethreaded Debug/Release
As opposed to the "DLL" versions of those libraries.
Even if you do that, depending on the libraries you're using, you might have to install a Merge Module/framework/etc. It depends on whether static LIB versions of your dependencies are available.
Be aware that Microsoft do not recommend that you static link the runtime into your project, as this prevents it from being serviced by windows update to fix critical security bugs. There are also potential problems if you are passing memory between your main .exe and .dll files as if each of these static links the runtime you can end up with malloc/free mismatch problems.
You can include the DLLs with the executable, without compiling them into the .exe and without running the redist tool - this is what I do and it seems to work fine.
The only fly in the ointment is that you need to include the files twice if you're distributing for a wide range of Windows versions - newer OSs need the files in manifest-defined directories, and older ones want all the files in the program directory.
You'd be looking to static link (as opposed to dynamically link)
I'm not sure how many of the MS redistributables statically link in.
If you are looking to find out which dll's your target machine is missing then use depends.exe which used to come with MSDev, but can also be found here. Testing this on a few target machines should tell you which dll's you need to package with your application.
You should use a static link and add all libraries you need under additional dependencies.