My code does not use MFC. However, when I built my static lib the party that is trying to use it is stating that they are having a hard time because my code lib has the following dependencies in it:
mfc80.dll and msvcr80.dll
Is there a way to remove those and rebuild? I am using vs2008.
A static library by default links to the dynamic runtime, which is why your code has a dependency on msvcr80.dll. Visual C++ programs must link to a runtime. You can change your static library to use a static runtime to remove the dependency. This is done in the Configuration Properties | C/C++ | Code Generation | Runtime Library setting. However, the chosen runtime library must match what is used in the project that links your static library.
Your code probably depends on mfc80.dll because you have Configuration Properties | General | Use of MFC set to one of the MFC options.
In my opinion, Visual C++ (and Windows in general) was made for dynamic libraries and dynamic runtimes. Static libraries seem like more of a hack, in that they have a surprising number of limitations, pitfalls and idiosyncratic behavior. Better become familiar with producing and consuming dynamic libraries -- it's better in the long run.
mscvr80.dll is the release CRT. You can remove this dependency by setting the compiler to statically link. Most likely, you're trying to load MFC because the project is set to use MFC, even though you're not using it. You can remove this in the project settings.
Although, gotta question why VS2008 would produce mfc80.dll and mscvr80.dll dependencies, instead of mfc90.dll and mscvr90.dll.
Related
Even having already dug through loads of info on the net about this, I am still having some trouble understanding the boost lib files. I have Boost 1.51 installed and the lib folder is 1.7GBs which is just too much. I need to reduce it.
Just to show an example:
http://i.imgur.com/6nXfVEr.png
That is all the regex lib folders. There are 10 of them! I want to delete most of these, but I struggle to understand, which folders I need.
I assume 'libboost' is the static lib (which doesn't require a DLL) and the others are dynamic which do. Does it mean if I use the dynamic libraries I need boost DLLs in my project?
I can also see some are debug and others aren't. Is it necessary to keep both? or can I just always use the non-debug versions for my projects?
Finally, am I right in thinking, to make Visual Studio choose specific libs I go to the:
C/C++ project settings -> Code Generation -> Runtime Library, and change between /MT, /MD, etc?
If I use Multi-threaded (/MT), does that mean I can remove all the debug libs and dlls because this option only uses the static libs?
Thanks for any advice.
I assume 'libboost' is the static lib (which doesn't require a DLL) and the others are dynamic which do.
Yes.
Does it mean if I use the dynamic libraries I need boost DLLs in my project?
Yes.
Finally, am I right in thinking, to make Visual Studio choose specific libs I go to the: C/C++ project settings -> Code Generation -> Runtime Library, and change between /MT, /MD, etc?
Not quite so. Setting /MT or any other similar option will only make your application use the corresponding versions of runtime libraries (e.g. CRT). It does not mean you can only link statically after this, neither does it "select" anything for your own project-specific dependencies.
Whether you link to boost as a static library or DLL depends on which .lib file (libboostXXX or boostXXX) you specify in: Linker -> Input -> Additional Dependencies. Also, you may need to visit Linker -> General -> Additional Library Directories and add a path to your boost/libs folder (and possibly its subfolders) so that you don't have to specify full path for each library you are adding to dependencies.
However, you should always (especially when using static libraries) link to libraries built with the same runtime which you have selected in your main project. If you try to mix different runtimes, you will most likely get pretty cryptic linker errors about double-defined symbols (in system libraries) and such. In the worst case (usually due to a mismatch in some less obvious settings, like preprocessor definitions that change STL options) it will not lead to a linker failure, but to mysterious runtime crashes. Visual Studio 2010 and later, however, does pretty good job of detecting such mismatches (compared to previous VS versions).
Another issue might be that some of the boost headers are using #pragma comment to force linking necessary libraries by a specific name. If you find this a problem and want to specify your dependencies manually (or if it selects something you don't really need to link to), you can add a global preprocessor define BOOST_ALL_NO_LIB to C/C++ -> Preprocessor -> Preprocessor Definitions.
Also, do you really need all of the boost libraries in your project? There's a lot of them, and most are for very special things. In my experience, people usually only need a small subset of boost for their project-specific goals. To create such a subset, containing headers only for the libraries which you really use, and their dependencies, you can use the BCP utility. This would probably reduce your boost/boost folder dramatically. And, of course, you can also delete binaries for the libraries you are not going to use. Also note that most of the general-purpose libraries in boost are header-only and thus don't require linking to any libraries at all.
I've tried Googleing this but I could not find a solution. I am trying to learn some basic C++. I wrote a simple hello world:
#include <stdio.h>
int main()
{
printf("hello, world\n");
return 0;
}
It compiled perfectly and everything! Great I thought, so I loaded up my virtual machine with XP and no service packs installed, then tried to run it. It told me I needed the MSVCR dll. Is there any way I can completely remove this dependency? I don't want to stuff the program with the dll. I want it to be gone, completely. Is it possible to make and run a program that will run in XP and up? Thanks.
It is technically possible to remove this dependency in C, but I'm not sure it is even possible in C++. And in either case, I would not recommend it. You lose a lot of stuff that the CRT does for you behind the scenes, most of which you don't want to have to reinvent yourself in an inferior fashion. For starters, it's the runtime library that actually calls your main function as well as calling the constructors and destructors for global and static C++ objects.
The best and simplest solution is probably to change how your application links to the runtime libraries. You have two different options: dynamically and statically. Dynamic linking is more memory-efficient and means that your application will take advantage of any bug fixes that are made to the library. It relies on the runtime DLL being present in order for your app to start. Static linking actually embeds the runtime library code into your application during the link phase of the build. This means that you can run without distributing the DLL, but there are important caveats.
For simple apps, it's unlikely that these caveats are relevant. Change the link style in use in your project's options:
Right-click on your project name in the Solution Explorer.
Expand the "C/C++" option in the left-hand treeview, and select the "Code Generation" item.
In the "Runtime Library" property combobox, choose one of the "Multi-threaded" options.
Debug builds should use "Multi-threaded Debug", while Release builds should use "Multi-threaded".
Do note that since you're using VS 2010, you can still choose to dynamically link to the runtime and gain all of the advantages of doing so without having to run the CRT installer on the target machines. All you need is the redistributable DLL(s) placed into the same folder as your application's executable. This makes deploying (and even testing) very simple and straightforward. You'll find these libraries as part of your Visual Studio installation:
\Program Files\Visual Studio x.0\VC\redist\
And of course, the debug versions of the CRT are never redistributable. Since you should not distribute debug versions of your application, this is not a problem. Make sure that you've compiled a "Release" build (using the drop-down combobox in the top toolbar), for which you will require only the redistributable libraries found in the above directory.
Can't I use the runtime that comes with XP?
There is no C runtime for you to use that comes with any version of Windows. Windows itself indeed depends on a C runtime library, but it deploys a private version of that library for its own use. Applications are not intended to link to it or make use of it in any way. You're on your own for deploying all necessary dependencies, and as you've noticed, you cannot assume that the target machines will already have the correct version(s) installed.
You can link the MS runtime statically, Project Options -> C/C++ -> Code Generation -> Multithreaded (or Multithreaded Debug for debugging configuration). No DLL should be needed then.
you can remove the annoying run-time library, do this:
project properties > linker > input > ignore all default libraries> yes
this will give you quiet a few issues you need to deal with, for example, floating
point numbers won't work, stack memory is very small (about 3k), there's no built in help against buffer overflows and such, and you can't use the standard library without copy pasting it in your project.
this will also decrease the size of the .exe nearly equivalent to as if it was hand made
in assembly.
A library i'd like to use makes calls to functions like "malloc_dbg" which are defined in libcmtd.lib but not in libcmt.lib (so I get Linker errors in Release mode)
Do I really need to use the debugversion of that lib even in releasemode? or can I somehow use libcmt.lib and libcmtd.lib together, but use libcmtd.lib only for this other library and use the releaseversion for the rest of my application?
Thanks!
Maybe you can implement malloc_dbg yourself and call malloc from there?
But this is just a workaround. The lib you are using should provide you a release version without these calls!
Since your question is
c++ What to do if Library makes use of debug version of other library?
Here's my advice, in this order:
Don't use this library. -- If the library doesn't even provide a proper release version, then it isn't fit for anything.
If you must, and as in your case it appears that the lib requires the static debug version of the runtime lib, then try to create a wrapper around this library so that your project can compile with proper settings.
Compile your project with the debug libraries. If you link statically to the runtime libraries, then you wont have a problem with redistribution and for small stuff it may be acceptable to use this approach.
Since you write in the comment you have this problem with GLUI I assume the fault is with you, not with the library. GLUI is an open source project, so you should be able to compile the lib (even an old version) with the appropriate settings for your environment.
I use MSVS 2010 and MSVC++E 2010 to build my applications in C++ and I've notice a lot of my friends (who test my apps on their PCs) don't have the Microsoft C++ runtime library installed on their computers. I've started including the Microsoft C++ redistributable package with my apps, but this seems unnecessary. Would I be able to instead include the libraries in my executable directory? I know that one of the libraries used is msvcr100.dll, but are there also others I need to include? Or is the redistro my best option?
in your project options, for code generation, you can choose the STATICally linked libraries instead of the DLL versions. That eliminates the need for an external dependency like this, at the cost of a larger EXE.
You don't necessarily need to HAVE to have the runtime library within your executable directory, you may use a Manifest File that has a relative path which points to runtime if you wish. But yes, you can include the libraries within the install of your application.
I think we lug around the msvcr as well as the msvcrt and the msvcp DLLs which now that I'm writing that out, might be a bit overkill.
When you build your application to a static runtime, you don't need to distribute the runtime dlls.
Otherwise you have to include the Microsoft runtime.
Links to runtime installers for Visual Studio 2010
Compiling your project with /MT solves the distribution problem. Be careful though, it can get you in trouble when you use DLLs. They will have their own memory allocator. If they export a function that exposes a pointer or a C++ object that needs to be released by the client code then you'll have a very hard to diagnose memory leak on your hands. Very easy to do, just return an std::string for example.
Anyhoo, the setting is found by right-clicking the project in the Solution Explorer window, Properties, C/C++, Code generation, Runtime Library setting.
Also note that VS2010 supports local deployment. Just put the msvcr100.dll file in the same directory as your EXE. You also need msvcp100.dll if you use STL or iostreams.
Why do some C++ projects require a runtime package to be installed, while others do not?
EDIT:How to make a project to work without the runtime?
Some will have been statically linked, while others will depend on a dynamic library, loaded at run-time. To link your own project statically, you need to change your project configuration - how you do this depends on the compiler/linker and/or IDE you are using.
Some applications are built linking with the system libraries this are the dynamic linked programs.
Other programs contains the code of the libraries into the executable file this are the static linked programs.
Pros of dynamic linked:
Smaller size of the program executable.
Less memory consumption if the dynamically linked library is shared.
Better performance.
Cons of dynamic linked:
Dependency on the library.
Deployment is more dificult.
Pros of static linked:
No dependencies.
Easier deployment of the application.
Cons of static linked:
The executable file is bigger.
To get a static project you need to set up the option in the project properties.
I think this refers to the VS2005 service pack 1 runtime. For some reason MS added some non-backward compatible features to it, so any app built with VS2005sp1 requires the runtime to go with it.
You need to have runtime package installed in case you are working with standard C/C++ library linked as DLL, and not as static library. So one way to avoid it is to link standard C/C++ library statically (C++ project settings). It may, or may not be possible in your case.
If not, you can use dependency walker tool from Visual Studio distribution to identify the DLLs needed by your application and just put them near your executable.
What you should be aware in Visual Studio 2005 and later is that there are the manifests for binaries can (and probably will :) make your life harder. Specially since SP1 for Visual Studio 2005 changes the version of C++ library, and the manifests as well.