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.
Related
I thought this should be straightforward but I am running into a bunch of linker errors like so:
Error 1 error LNK1104: cannot open file '...\Debug\Utils.lib' ...\LINK
where Utils is one of the C++ projects I want to keep as DLL.
If I change Configuration Properties->Configuration Type to Static Library(.lib) everything compiles and runs fine, but if I use .dll then its not working.
The whole solution is native C++ with the main project being a win32 console application.
Perhaps your library (Utils.lib) is not assembled as DLL and changes in console application project (that uses library) will not help.
Read carefully MSDN to see features of DLL's creation and usage.
It you try to link a .lib against another .lib, it doesn't really link. Instead, this instructs the final link to use both libraries.
For a DLL, this can't work, as the runtime linker cannot link the original .LIB. That means the link has to happen when the DLL is compiled.
As a result, a DLL project needs to have the .LIB directories set right.
If .lib files are for static linking and .dll files for dynamic linking why can I specify in C/C++ -> code generation -> runtime library options select multi threaded or multithreaded DLL when building an explicitly static library (ie when making a .lib) or when building a project and linking to a .lib library?
Visual Studio allows you to specify how the CRT is going to be integrated into your project under C/C++->Code Generation->Runtime Library. This project setting controls how C/C++ routines used explicitly or internally (e.g. exception functions or STL routines) are going to be linked to your project.
You can create a static library which uses the CRT dynamically or statically by specifying the /MT or /MD flag during compilation.
Regarding advantages/disadvantages I'm linking this answer which features a pretty good list of points to keep in mind.
One last thing to notice: if your project is going to use multiple static libraries (including your .lib file), you should make sure that this CRT option matches during the linking phase otherwise you might encounter the (in)famous LNK4098 error.
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.
Using Visual Studio 2010 C++. I have a project which uses MFC and I am statically linking to MFC. I am in the process of trying to extract the non-GUI functionality into a separate static library project. Because I want to use CStrings in my library project (debatable whether I should, but for the sake of argument) I now need to reference MFC in both my library and my exe projects.
My question is if I statically link with MFC in my library project and in my exe project, will I effectively have two copies of MFC linked in my final exe? What if I added a third project so I had multiple libraries referencing mfc? That sounds bad but I'm not sure how to get around it.
You don't need to link a library project, so there won't be an extra copy of MFC being linked in. You'll be creating a dependency on the MFC library from your static library, but that's normal. As long as the .exe project includes both libraries, everything will come out all right in the end.
In my Windows CE DLL project, I am trying to tell Visual C++ to link statically to MFC in a project that originally did not use MFC. However, upon linking successfully, Dependency Walker (depends.exe) says that my DLL is dynamically linked to MFC80U.DLL and MSVCR90.DLL. Has anyone else encountered this bug?
If "Use of MFC" is set to "Use Standard Windows Libraries", and the code that needs MFC is removed, neither of these DLLs is linked in. How can I get true static linking to MFC and standard libraries?
It seems I was linking to a static library, made by another developer, that was configured to link dynamically to MFC. Apparently Visual C++ decided to ignore my requests for static linking and used the dynamic link setting from the static library. After I obtained a new version of the library that was set to use static linking, the dynamic linking disappeared.