I wonder if I need to distribute VC++ runtime when I only write simple console applications using Visual C++ 2015.
No DLLs etc... just static linking of the standard library (and my own libraries).
You can self-service this: use a clean VM OS installation to check.
But, the answer is: no. be sure to set c/c++ > code generation > runtime library to Multi-threaded or Multi-threaded Debug, as appropriate. Generally during development, it's convenient to use dependency walker periodically to verify your exe isn't importing any DLLs.
Related
Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
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.
In my DirectShow application I have a third party DLL (a 32bit DirectShow filter) that I don't have source for that links against the 32bit Windows version of Intel Threading Building Blocks (tbb.dll).
If I want to use Threading Building Blocks in my own DLL in the same process (e.g. another 32bit DirectShow filter) does this force me to use the same version of Visual Studio that the author of this third party DLL used?
EDIT - I've realised that the version independent _mt library is probably the best one to use in this scenario. What happens if third party vendors haven't built for this _mt dll?
In my own Threading Building blocks installation I notice that there are different versions of tbb.dll for different versions of Visual Studio - 2005, 2008, 2010 and 'MT' (not sure what that is yet). One obvious reason for this is that the different versions of tbb.dll link against different versions of the Visual Studio runtime library DLLs. Is it possible to tell which version of tbb.dll is required by inspection or do I have to grub around looking for strings in the binary indicating the compiler version used (the third party DLL appears to be linking the visual studio runtimes statically)?
As far as I can tell tbb.dll doesn't use manifests and side by side versioning and is given the same name for different compiler versions. A last resort would be to rename the different tbb.dlls and hack the import library or imports to reference the renamed dlls but I'd really rather avoid this. Is there a clean way to redirect the imports with linker options?
As these DLLs are well behaved DirectShow filters they won't be passing Visual Studio runtime or TBB objects between them which would clearly be dangerous. Their interaction will be limited to calling each other via standard COM DirectShow calls.
If you are not using TBB, the question is only about Visual Studio versions, then you don't have to worry: Visual C++ Runtime DLLs have different names across versions, e.g. MSVCR70.DLL, MSVCR90.DLL etc. And, as you already discovered, /MT switch will compile/link a static version of runtime and will embed the stuff into your DLL without having to worry about sharing right DLL with a peer DLL.
I've just recently started working with Visual Studio this summer, primarily on CUDA and OpenCV related projects. Prior to this, I had been doing my development on Linux for CUDA using Makefiles and the common.mk makefile from NVIDIA.
So my question is as follows: I've not been able to figure out for the life of me what the difference between some of the different project templates are. I know that I've had to use "Empty Project" from the general tab of the Visual C++ options, but that's more trial and error, rather than actually knowing what is going on...
A Win32 project is used if you want to end up with a DLL or a Win32 application usually using the bare WinAPI. A common language runtime (CLR) project is used to create C++/CLI project, i.e. to use C++/CLI to target the .NET platform.
The main difference between projects is what Visual Studio comes up with in terms of pre-created files. A windowed Win32 application for example (what you get when you choose Win32 project, but not a DLL) is created with a file for resources (menus, accelerators, icons etc.) and some default code to create and register a window class and to instantiate this window.
When creating a Win32 project, the linker Subsystem is set to Windows. When creating an empty C or C++ project the subsystem is set to console. Likewise the entry point in the settings for Win32 projects expects a WinMain or DllMain while a console expects an int main. A CLR allows you to mix C++ and .NET which is usually discouraged against.
A Windows subsytem can target executables, dlls, libs or driver/native(sys) files. While a console subsystem targets console binary executables. WinMain is typically used when creating an actual Window application using the CreateWindowEx API, establishing message callbacks and inserting a message handler loop.
A console subsustem with int main can also create a Windowed application only you're better off doing it with WinMain.
A Dll empty project sets the subsystem to Windows and setting to the compiled output to (.dll) as well as the entry point to DllMain/APIENTRY and a static lib will do the same as the Dll except it will set the output to (.lib).
Setting the project to Native subsystem will require the Windows Driver Development Kit to compile drivers.
I have designed an application that requires no install and can be used by non-administrators. I would rather not lose this functionality but when I use the .exe on other computers than the one I programmed it on I get an error that a missing MSVCP100.dll is preventing the file from executing.
What am I doing wrong here? How do I include the file in my release build?
Thanks!
Configure your project to statically link to the C/C++ runtime instead of linking to the runtime DLL:
Configuration Properties | C/C++ | Code Generation | Runtime Library
Select Multi-threaded (/MT) (or Multi-threaded Debug (/MTd) for your debug build).
As an alternative, you should be able to get xcopy deployment of the C/C++ runtime DLL using the technique documented on http://msdn.microsoft.com/en-us/library/ms235291.aspx under the heading "Deploying Visual C++ library DLLs as private assemblies". I haven't tried that technique, as it's generally simpler to just statically link if you need xcopy installation of a native C++ program.
http://msdn.microsoft.com/en-us/library/ms235299.aspx
Distributing apps that have been compiled with Visual C++ requires distributing the C++ runtime .dlls that your app uses. In your case, I assume you want to just distribute a folder, so follow the directions (appropriately modified for your app) here:
http://msdn.microsoft.com/en-us/library/dd293565.aspx
Or just copy msvcp100.dll into your application's directory alongside the .exe and you'll be good to go.
32-bit msvcp100.dll is in C:\Windows\SysWOW64\
64-bit msvcp100.dll is in C:\Windows\System32\
What am I doing wrong here
What you had was dll hell. You had unintentionally used a dynamic linkage with the previous compiler where it just happened on most target systems there was an appropriate C runtime. Windows often included VC 6 CRT, and with more recent SP even VC7 & 8 CRT.
When you changed to the latest VC compiler most systems will not have the new VC runtime pre installed for you.
As Michael Burr says, you can have your 'no install' back if you link statically.
Or you could include the CRT and manifest in the same folder, still doesn't require install.
Or include the vcredist.exe from VS2010 and have a 1 off install
You need to install Microsoft Visual C++ 2010 Redistributable Package.