Good Afternoon, so I have a question about including the aux_klib library in my Kernel Mode Driver, for some reason I get the same error for all aux_klib functions.
Error 1 error LNK2019: unresolved external symbol AuxKlibInitialize referenced in function "unsigned char __cdecl Main(struct MainInfo*)" (?MainInfo##YAEPEAU__MainInfo###Z)
I did #pragma comment(lib, "aux_klib.lib") in my project and no luck, also the driver is coded in cpp. I also added the lib to my project and made sure it was x64 as that is the projects build architecture. I also tried including the function via extern "C" with out the header and just the lib but no luck, I also added all the library paths to the linker settings and what not. Any ideas are welcome!
Properties->Linker->Input->Additional Dependencies add "AUX_KLIB.LIB"
This worked for me
I had the same problem with linking Aux_klib.lib, so I set /VERBOSE:Lib.
Right click on the project -> Properties -> Linker -> General -> Show
Progress
As I understand it, For Libraries Searched /VERBOSE:Lib shows the libraries search and I've noticed that Aux_klib.lib is not in that search.
And I noticed another thing in the output, /NODEFAULTLIB is passed in the command line as well.
As #RbMm says,
are he search for aux_klib.lib may be you used /nodefaultlib option.
in this case #pragma comment(lib, "aux_klib.lib") will be have no
effect.
So I changed Ignore All Default Libraries
Right click on the project -> Properties -> Linker -> Input -> Ignore
All Default Libraries
to No and everything linked and compiled perfectly.
TL;DR
In short, try to change Ignore All Default Libraries under Linker to No and use #pragma comment(lib, "aux_klib.lib").
Related
I'm currently attempting to compile a VST3 plugin (or any C++ code, for that matter) for the first time, mainly just following Steinberg's own tutorial for all things except the actual sound processing.
Attempting to compile throws an "unresolved external symbol" error:
Error LNK2019 unresolved external symbol "public: __cdecl VSTGUI::VST3Editor::VST3Editor(class Steinberg::Vst::EditController *,char const *,char const *)" (??0VST3Editor#VSTGUI##QEAA#PEAVEditController#Vst#Steinberg##PEBD1#Z) referenced in function "public: virtual class Steinberg::IPlugView * __cdecl Itisdud::Split_TimesController::createView(char const *)" (?createView#Split_TimesController#Itisdud##UEAAPEAVIPlugView#Steinberg##PEBD#Z) Split_Times D:\programme\VST3Dev\Split_times\Split_Times\build\split_timescontroller.obj 1
The function that causes this, createView, is still the default it is when created by the Project Generator:
IPlugView* PLUGIN_API Split_TimesController::createView (FIDString name)
{
// Here the Host wants to open your editor (if you have one)
if (FIDStringsEqual (name, Vst::ViewType::kEditor))
{
// create your editor here and return a IPlugView ptr of it
auto* view = new VSTGUI::VST3Editor (this, "view", "split_timeseditor.uidesc");
return view;
}
return nullptr;
}
Copying the createView function from the again and adelay samples didn't work either.
As the Project generator only includes vstgui4/vstgui/plugin-bindings/vst3editor.h and not the vst3editor.cpp file, I tried including that as well (As I've read that not having the actual implementation there might be the cause of the issue), however that didn't fix the issue but made a lot of other errors happen upon compiling.
I also tried to follow this, including the cpp files noted there and changing the createView function to what is written there, however this also only led to there being a bit more than 300 errors upon compiling.
Copying the includes from the again sample didn't work either.
What would I need to include for this to work?
Those are the linker errors as you didn't instruct the linker where to find the required library files whose functions you are using.
Remember that compilation is a 2-step process that involves compilation and linking so it is best to separate them.
Lets assume you are using Visual Studio on Windows, and lets assume your VST SDK is installed on
C:\VST3SDK.
The first thing you should do is fire-up Visual Studio and select File->Open->CMake and go locate the CMake.txt file here
C:\VST3SDK\VST3_SDK.
After this file is loaded you will find on Visual Studio Solution Explorer a list of ready-made projects that come with the VST SDK loaded.
You will find that one of these projects is called Libraries and that is THE first action you have to do.
Now you have to build the correct library depending on whether you want to make 32-bits or 64-bits VSTs and you should set the configuration of the Libraries project accordingly.
You will build these libraries and if you hadn't changes any setting the libraries will be found at
C:\VST3SDK\VST3_SDK\out\build\x64-Debug\lib
or
C:\VST3SDK\VST3_SDK\out\build\x64-Release\lib
the necessary libraries being:
base.lib
pluginterfaces.lib
sdk.lib
sdk_common.lib
sdk_hosting.lib
vstgui.lib
vstgui_standalone.lib
vstgui.support.lib
vstgui_uidescription.lib
The above step ensures that you now have the necessary library files your VSTs will depend on.
Now assuming you have a VST sample project, lets say that you got from Git-hub and that it were written and setup correctly to run on Visual Studio, i.e. it came with a
myVST.vcxproj file.
Then you could paste the following pragmas on a prominent VST file such as the factory.cpp
#pragma comment(lib, "base.lib")
#pragma comment(lib, "pluginterfaces.lib")
#pragma comment(lib, "sdk.lib")
#pragma comment(lib, "sdk_common.lib")
#pragma comment(lib, "sdk_hosting.lib")
#pragma comment(lib, "vstgui.lib")
#pragma comment(lib, "vstgui_standalone.lib")
#pragma comment(lib, "vstgui_support.lib")
#pragma comment(lib,
"vstgui_uidescription.lib")
(Had to abbreviate due to confusing formatting requirements of this site but replace like "vstgui.lib" with a fully qualified path like
"C:/VST3SDK/VST3_SDK/out/build/x64-Debug/lib/vstgui.lib"
Now if your project properties
C/C++ _> General _> Additional Include Directories has correct entries that will tell the compiler the paths it will find ALL the #include files, then you will find that if you right click on any compilable file (c, cpp, rc ...) and select Compile then the file should successfully compile into an object file without any Compiler errors otherwise it is an indication that the compiler cannot find the required header
files.
But the problem you face are the linker problems, the linker can not find the required libraries of functions you have used in your project and the solution is just pasting the pragmas above.
I am trying to statically link this library into my VS C++ project.First I compiled the source as a static lib.Linked it via VS Project properties.The .exe project works fine.Then I read this MS manual on how to compile the static lib into the executable and following the steps outlined there now if I am running the executable I am getting these errors:
Error 3 error LNK2019: unresolved external symbol __imp__glBlendFunc#8
referenced in function _text_buffer_render E:\Documents\visual studio
2012\Projects\XXXXEngine\FreeTypeTest\text-buffer.obj
Error 4 error LNK2019: unresolved external symbol __imp__glBindTexture#8
referenced in function _text_buffer_render E:\Documents\visual studio
2012\Projects\XXXXEngine\FreeTypeTest\text-buffer.obj
To me it seems like GLEW.lib errors.Does it mean I have to link also glew.lib statically as the freetype GL depends on it ?
Also, can I just use the lib with the executable without adding it to references, or it won't work in release build?I am asking it as I am quite confused with how the static linking should be done.I mean,now the executable works without adding the library to the project reference.Then why can't it be used just like this?
To me it seems like GLEW.lib errors
They are not, glBindTexture() is an OpenGL function. The MSDN library page is here. Scroll to the bottom, it shows you the .h file that declares it (you already that right since the compiler didn't complain) and the .lib you need to link.
Right-click your project, Properties, Linker, Input, Additional Dependencies setting. Add opengl32.lib. Or to use the upvoted answer's suggestion, you can inject the linker directive in your source code:
#include <gl\gl.h>
#pragma comment(lib, "opengl32.lib")
Have you tried to pragma mark your library?
Like so:
#pragma comment(lib, "any.lib");
I'm trying to compile a c++ source code file from the DXC competition.
The instructions are:
To compile any of the C++ examples (or a DA written in C++) under Windows, MS
Visual C++ 8.0 (2005) is required. Make sure to add %DXC_HOME%\Lib and
%DXC_HOME%\Include to your library and header search paths respectively, and add
dxcApi.lib to your list of libraries (or dxcApid.lib if compiling in debug
mode).
I added Lib and the Include libraries to the library and search paths and it imported them. What I didn't understand is the meaning of the second step: "add dxcApi.lib to your list of libraries" - what does it mean?
Without this step I'm getting linker errors, such as:
Error 1 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: _thiscall
Dxc::CandidateSet::~CandidateSet(void)"
(_imp_??1CandidateSet#Dxc##QAE#XZ) referenced in function "public:
void __thiscall ExampleDA::sendDiagnosis(void)"
(?sendDiagnosis#ExampleDA##QAEXXZ) D:\Dropbox\Work\Visual Studio
2010\Projects\DXC11\DXC11\ExampleDA.obj DXC11
I'm stuck with this problem for quite some time now and I'm desperate for help!
Thanks a lot
You need to add the specific lib file to the libraries list, so that the linker can search it for the symbols you're missing.
The task says to add that particular .lib to the list of libraries that get linked to your code. Without saying that this library should be linked, the implementation for the functions defined in its headers is not available to the linker and you get that unresolved external symbol.
In VS, you can add something to the linked libraries list either through a #pragma comment or in the project settings:
// at the top of main.cpp, preferrably
#pragma comment(lib, "the_lib_name.lib") // .lib optional
You can have different libraries for debug and release with simply surrounding the #pragma comment in an #if block:
#ifdef NDEBUG // release
#pragma comment(lib, "the_lib_name.lib")
#else // debug
#pragma comment(lib, "the_lib_named.lib") // most debug libraries end with a 'd'
#endif
And for the project settings you can do so with
[Project] -> <Project Name> Properties (or Alt-F7) -> Configuration Properties
-> Linker -> Input -> Additional Dependencies
Just add the_lib_name.lib at the front (followed by either a space or a semi-colon ;). Make sure you add the correct library for the active project configuration (debug / release).
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.
I am building an application as a library, but to make sure I can get the output that I'd like, I switched it over to produce an exe. As soon as I did, I got several errors about unresolved external symbols.
At first I thought that I didn't have a path set to the 3rd party library that I was referencing, so I added the folder to my path variable and even added it to my include, references, and source files, just to make sure I had all the paths.
I still get the error:
error LNK2019: unresolved external
symbol "__declspec(dllimport) public:
static void
__cdecl xercesc_2_8::XMLPlatformUtils::Initialize(char
const * const,char const *
const,class xercesc_2_8::PanicHandler
* const,class xercesc_2_8::MemoryManager *
const,bool)"
(__imp_?Initialize#XMLPlatformUtils#xercesc_2_8##SAXQBD0QAVPanicHandler#2#QAVMemoryManager#2#_N#Z)
referenced in function "void __cdecl
xsd::cxx::xml::initialize(void)"
(?initialize#xml#cxx#xsd##YAXXZ)
The reason that I'm asking it here is because in Visual Studio, when I built it as a library, I didn't get these errors, but as a dll and exe, I do.
Anybody have any thoughts?
Building a library, the linker doesn't need to resolve imported symbols. That happens only when it starts linking object files and libraries together.
That's why you only started seeing the error when building an executable.
Indeed, in VC2008 (and 2005, if I remember well), use the project properties -> Linker -> Input -> Additional dependencies. The libraries you need are to be separated by spaces (odd, hey?)
Good Luck!
You also need to specify that you wish to link against that library in particular. The link paths merely tell the linker where the data you need to find is, not what to look for. You will also need to specify that you are linking against the library in question (xerces?).
Unfortunately, I don't know how to specify this in MSVC, but it's probably somewhere under 'Linker Options'.
As #coppro said, you need to specify that you want to link with that library. When you build an EXE or DLL, a linker is run, and it needs to find all the functions you are using, but to build a library, the librarian is run, and it doesn't have to resolve all function references (but when you use that lib in an EXE, you'll have to, again).
So go to the project's options, Linker Options, Input, and list the library that defines the missing function (xerces.lib?) under Additional Library Paths. You might need to add its location under Additional Library Paths.