can someone please help me to understand the process.
in c++ visual studio 2010
i have a visual studio solution (lets call it mysol)
i have a project built as a static library (let's call it staticprj)
staticprj needs to use a library from outside (lets call it ext.lib)
in the body of the source code of staticprj i include outside library header file with
# include extlib.h and make calls to some of its functions (let call them extfunctions())
i also include the the path to the header files location of the ext.lib.
the staticprj compiles okay without errors
the mysol also has another project which is a dynamic library (dynprj) and which depends on the staticprj.
also in the source files of the dynprj uses functions from outside library.
i have included #include extlib.h in the source code of dynprj.
i have included the path of the header files
i have attached extlib.h directly to the dynprj
i have also added ext.lib to the linker input (along with the path where the ext.lib resides).
i still get a lnk2001 error stating that extfunctions() where not found.
the whole structure (the mysol solution) compiles okay if i do not use ext.lib at all.
my question is how does the linking process works and what can i do to correct this linking error.
(note that without the presence of ext.lib my linking of the staticprj and dynprj is fine. my compilation works okay and my code works. i only get the linking error when i try to link another ext.lib to staticprj and dynprj and use functions from ext.lib)
thanks in advance.
I'm not quite sure it will work, but try putting the .dll inside your "mysol" debug folder. I had a similar problem couple of weeks ago when I had library compiled as .dll. I just placed that .dll within my debug folder and worked lovely.
I have a solution with two projects on VS2010.
The main project references and depends on the second one, which is built as a static library. The second one uses a static third-party library that is not build within the solution, but is only referenced in the second project's linker settings.
If I try to generate the solution, VS fails and indicates that he didn't find the third-party library. I do not understand why, since the second project's compiled static lib is big enough and seems to "contain" the 3rd-party library.
So far, I see only two solutions to my problem, which I would rather avoid:
Add the 3rd-party library to the main project's linker settings
Include the whole 3rd-party library in my solution and compile it with
Is there any other way to resolve this problem?
EDIT : The problem occurs when compiling the main project, the compiler outputs : LINK : fatal error LNK1104: cannot open file 'wxbase29u.lib' (I'm using wxWidget in my second project)
EDIT2 : I put the -verbose option for linking on, and it seems like the references to the 3rd-party library actually still exists in Project2.lib :
Searching ..\MyAppConfig\Bin\Win32\Release\MyAppConfig.lib :
"public: static void __cdecl ConfigWindow::Open(void)" (?Open#ConfigWindow##SAXXZ) found
Referenced in main.obj
Loaded MyAppConfig.lib(configWindow.obj)
/DEFAULTLIB:wxbase29u processed
/DEFAULTLIB:wxbase29u_net processed
/DEFAULTLIB:wxbase29u_xml processed
/DEFAULTLIB:wxregexu processed
/DEFAULTLIB:wxexpat processed
/DEFAULTLIB:wxjpeg processed
/DEFAULTLIB:wxpng processed
/DEFAULTLIB:wxtiff processed
/DEFAULTLIB:wxzlib processed
...
...
LINK : fatal error LNK1104: cannot open file 'wxbase29u.lib'
Funny thing is that I don't even use the other wxWidgets libraries in Project2, but visual studio seems to be searching for all of them though :/
Here's how you should setup your project:
Project 1 (main)
Additional dependencies: Project2.lib
Project 2
Additional dependencies: ThirdParty.lib
Build order: Project 2 -> Project 1
If your project is setup like that and it does not link, then it just means the path to your libraries isn't correctly set (under "Additional include directories"). So just make sure that your project additional dependencies are correctly set and that the include directories point to the place where the libraries you need are located.
I have been able to work in the same project for sometime now, writing and successfully running c++ code. However, I discovered that I am still missing some essentials on how to export my .h files to another project and successfully use them in there.
I created a second project, project B to test the classes I have in project A.
visual c++: #include files from other projects in the same solution
I added the path of the header file in Project A into the Additional Include Directories(C\C++>general and Linker>general) section in the project configuration of Project B. I tried following the tutorials on this page http://msdn.microsoft.com/en-us/library/ms235636.aspx but I still end up with the error below
** LINK : fatal error LNK1104: cannot open file 'C:\Users\LaC\Projects\OSGB\Debug\OSGB.lib**
I would appreciate any help in understanding exactly how this is done so that in future, when I encounter this problem, I can know how to troubleshoot.
The code below is all I am working with.
IN PROJECT A
=============
//Utility.h
class Utility
{
private:
protected:
public:
Utility(void);
~Utility(void);
double square_root (const double);
};
//Utility.cpp
#include "StdAfx.h"
#include "Utility.h"
Utility::Utility(void)
{
//do nothing for now
}
Utility::~Utility(void)
{
//do nothing for now
}
double Utility::square_root (const double)
{
return 0;
}
IN PROJECT B
===============
#include "gtest/gtest.h"
#include "Utility.h"
TEST (SquareRootTest, PositiveNos) {
Utility u;
EXPECT_EQ (50.3321, u.square_root (2533.310224));
}
There are two (general) ways to include files into your project:
Make them a part of your project (adding them from the solution explorer) OR
Import them as a library (static or dynamic linking)
If you make them part of your project, then you have to add the header and the source files in order for the project to compile correctly. However, that's usually not what you want to do, as it defeats the purpose of having external libraries.
The second case is to use the external libraries, which requires that you:
Include the header files which are exported by the library in your C++ properties.
For static linking: you also have to include the *.lib file (the output of building the library) in the Linker properties.
OR
For dynamic linking: see tutorial.
So remember: there are two parts to building a C++ project- compiling and linking.
Compiler Errors:
If you get an error whose code starts with C* (e.g. C1083) and is related to problems header with the files, then check the Properties-> C/C++ -> General -> Additional Include Directories.
Linker Errors:
If you get an error whose code starts with LNK*, then check
Properties -> Linker -> General -> Additional Library Directories (make sure that this points to where the *.lib file is located)
AND
Properties -> Linker -> Input -> Additional Dependencies (make sure that the *.lib file is added here).
If you're dynamically linking, then check that you're correctly referencing the DLL.
So in your case, you have to determine if you're linking statically or dynamically and then make the appropriate references. So ware you getting those header files from a dynamically library or a static library?
When the linker emits unresolved external symbol for a symbol that lives in another library (DLL or shared library), this indicates that you need to link your app to that other library's .lib file. That is most likely what's happening here.
For more information see:
(MSDN) Walkthrough: Creating and Using a Dynamic Link Library (C++)
I was advised by some of you not to long ago to use FreeImage as a library for image processing in C++.
I now have some trouble in getting the library to work (still relatively new here).
I've tried loading the various vcxproj and sln tiles and they gave me a blank project. Since there isn't any installation instructions provided for that, I gave up on making it a visual studio solution.
I next tried the old-fashion way of compiling the source code using the Makefile and then adding "FreeImage/Source" to the linker. While the IDE does not raise any red flags when I call functions declared in FreeImage.h, it gave me a bunch of "error LNK2019: unresolved external symbol" during compilation, as if the functions do not exist. What I suspect is that the IDE could not find the .cpp files that define the said functions, but I still get that same problem when I added FreeImage/Source/FreeImage to the linker.
Now when I directly included some of the .cpp files (i.e. Plugin.cpp and FreeImage.cpp) for a test, I get even more unresolved external symbol errors as well as things like "inconsistent dll linkage" for this within... for example FreeImage.cpp:
const char * DLL_CALLCONV
FreeImage_GetVersion() {
static char s_version[16];
sprintf(s_version, "%d.%d.%d", FREEIMAGE_MAJOR_VERSION, FREEIMAGE_MINOR_VERSION, FREEIMAGE_RELEASE_SERIAL);
return s_version;
}
So, I am totally stuck. What am I doing wrong? I felt I've followed the adequate steps in adding library dependencies, such as adding the specific folders that are immediate parents to the relevant .h and .cpp files in C/C++ -> General -> Additional Included Directories and Linker -> General -> Addition Library Directories.
Some help will be greatly appreciated!
Using FreeImage v3.15.3 I had no problems converting the VS2008 project to VS2010.
Also the building worked as expected. But when I linked to the static lib, I got some unresolved externals. First I tried al kinds of tricks setting /MT /MD linking, but that did not solve these linking problem.
After reading Some Newbie's comment I dug into freeimage.h. There I found a macro switch FREEIMAGE_LIB that controls the calling conventions of the function.
Use a #define FREEIMAGE_LIB before including the freeimage.h file. That way you can easily static link to FreeImage.lib
I am getting this linker error.
mfcs80.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRT.lib(dllmain.obj)
Please tell me the correct way of eliminating this bug. I read solution on microsoft support site about this bug but it didnt helped much.
I am using VS 2005 with Platform SDK
I had the same error message, but none of the answers here solved it for me.
So if you Encounter that Problem when creating a DLL Project that uses MFC, it can be resolved by entering the following line:
extern "C" { int _afxForceUSRDLL; }
to the cpp file where DllMain is defined. Then your own DllMain implementation is used, rather than the one from dllmain.obj.
When we try to use MFC library, we surely will include afx.h directly
or indirectly, then MFC(afx.h) tell the linker to find the symbol of
__afxForceUSRDLL and put that object which contains __afxForceUSRDLL into the program, so linker searches and puts dllmodule.obj into our
program, because __afxForceUSRDLL is defined in dllmodule.cpp.
That’s the common scenario. When we want to use our own DllMain in a
mfc dll project, linker complains that there are two DllMain, one in
our code, one in Dllmodule.obj.
So we need to tell the linker to add our dllmain.obj for
__afxForceUSRDLL. So we need to define __afxForceUSRDLL in our own cpp file where our own DllMain is defined, then the linker will ignore
mfc’s dllmodule.obj and see only one DllMain and never complains.
Source: http://social.msdn.microsoft.com/Forums/en-US/0d78aa6b-1e87-4c01-a4a7-691335b7351a/how-to-build-mfc-application-dll-in-visual-c-2010
If you read the linker error thoroughly, and apply some knowledge, you may get there yourself:
The linker links a number of compiled objects and libraries together to get a binary.
Each object/library describes
what symbols it expects to be present in other objects
what symbols it defines
If two objects define the same symbol, you get exactly this linker error. In your case, both mfcs80.lib and MSVCRT.lib define the _DllMain#12 symbol.
Getting rid of the error:
find out which of both libraries you actually need
find out how to tell the linker not to use the other one (using e.g. the tip from James Hopkin)
If you're defining your own DllMain, in your project settings you need to set 'Use of MFC' in the 'Configuration Properties/General' to 'Use Standard Windows Libraries'.
You should do a clean rebuild after changing it.
In my project I was able to solve this problem by adding mfcs80.lib and msvcrt.lib as additional dependencies in the project settings. The 'additional dependencies' can be found under Linker -> Input.
In the debug configuration that would have to be mfcs80d.lib and msvcrtd.lib respectively.
By the way, I am working with Visual Studio 2010, so in my case the MFC lib is called mfc100.lib.
I am not sure why this worked. It is not necessary to add these lib files as additional dependencies because I already set 'Use of MFC' to 'Use MFC in a shared dll'. I guess that by specifying these libraries as additional dependencies they are linked in a different order.
This solution is more or less the same as the one suggested on the Microsoft site: http://support.microsoft.com/kb/148652, except I did not need to type anything in the 'Ignore specific default libraries' box.
For me the direct cause was indeed a missing _afxForceUSRDLL symbol reference, but the indirect cause was a missing _USRDLL macro definition. It is defined by default by the VC wizard, but occasionally devs erase it erroneously.
Here it is in more words.
MSDN knowledge base ID Q148652.
http://support.microsoft.com/kb/148652
Cause:
Visual C++ compiles the source files in alphabetical order, and passes the compiled object files to the linker in alphabetical order.
If the linker processes DLLDATAX.OBJ first, the source code references DllMain, which the linker loads from MSVCRTD.LIB(dllmain.obj).
The linker then processes an object file compiled from a C++ file that contains #include "stdafx.h", which references the symbol
__afxForceUSRDLL, which the linker loads from MFC42D.LIB(dllmodul.obj). This object module also contains an implementation for DllMain,
causing the conflict.
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and the solution was add mfcs110d.lib to Additional Dependencies
For all those who are experiencing this error in ATL projects (mostly when trying to add MFC support), here's the solution I found after days of frustration!
First of all, this link was more helpful to me than all the others. It pointed me into the right direction. The problem occurs, if the "generated files" (containing the proxy and stub code, just as the type guids) for some reason have been removed and readded to the project. This causes Visual Studio to add them in the wrong order!
Usually you first come up with the "ATL requires C++ compilation" error, but you may have fixed this by turning out the Yc/Yu (precompiled headers) setting for that file.
What you should do next is unloading your project and edit it. Search for the item groups that define the build and include order (ClCompile and ClInclude). Check their order and settings.
The compiles should appear in this order:
dllmain.cpp (with CompileAsManaged set to false and PrecompiledHeader left empty).
Library source (MyLib.cpp, containing DllCanUnloadNow and so on)
Proxy/Stub code (MyLib_i.c; with same settings as dllmain.cpp)
stdafx.cpp (with PrecompiledHeader set to Create)
All the other library source files (your actual libraries content)
xdlldata.c (with the same settings as dllmain.cpp)
The includes should then be ordered like this:
dllmain.h
MyLib_i.h
Resource.h
stdafx.h
targetver.h
... (actual library headers)
xdlldata.h
Fixing the build order fixed my project and I was able to create a new clean build.
I have personally got rid of this error this way: right-clicked project in the Solution Explorer, selected Properties from pop-up menu, clicked Linker tab and added mfcs71ud.lib into Additional Dependencies. If you're using Visual Studio 2005, it should be "80" instead of "71" and so on.
In my case I had a problem with the preprocessor directives.
For some reason _USRDLL was defined, when it should not have been.
To check this, go to the menu Project , select Project Properties , then select the snippet Configuration Properties --> Preprocessor .
The preprocessor directives will be found there.
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional Dependancies field in the Project Properties -> Linker Tab -> Input of Visual Studio to fix the issue.
Just #undef the _USRDLL before including afx.h, or even better, edit your project configuration and remove the macro.
This is the usual configuration for a MFC extension DLL: Build Settings for an MFC DLL
Make sure you include "Stdafx.h" at the top of each .cpp file. I was getting the exact same error and had a single .cpp file that did not include this header at all. Adding the #include solved the problem.
I found solution Here
Visual Studio 2010 library linking order
this is: /FORCE:MULTIPLE
in linker options
I had to mix ATL and MFC together , to use
[module(name = "mymodule")]; construction in MFC application together with "__hook" keyword
I found this which helped me:
http://support.microsoft.com/kb/148652
Basically the linker order was incorrect. the CRT libs were getting linked before the MFC libs. Turns out, the MFC libs had to get linked FIRST, and then the CRT libs could be linked.
Yucko Microsoft!!
There is a common theme running through some of the answers here.
Avishek Bose:-
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional
Dependancies field in the Project Properties -> Linker Tab -> Input of
Visual Studio to fix the issue.
vmb100:-
I am working with Visual Studio 2010, so in my case the MFC lib is
called mfc100.lib.
joseAndresGomezTovar:-
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and
the solution was add mfcs110d.lib to Additional Dependencies
So the general case seems to be to first find the name of the library to add ...
and then to add it ....
Note that there seem to be some prerequisites and/or alternative solutions.
This can also occur if your solution has multiple projects that export the same symbols. For example if you have sub-project that builds foo.dll with a foo.def file that exports DoFoo and a sub-project for bar.dll with a bar.def file that exports DoFoo, a collision will occur and this is the error you will see when you link.