I have a VS2013 project with a class in a separate file where I want to
use the BeaEngine to disassemble a binary. I added all the necessary
files (BeaEngine.h and BeaEngine.lib) to the project and set the linker
to include the .lib. When I call the Disasm function from inside the
main() function my project compiles just fine, but when I try to call it
from inside one of the member functions of my class, I get the following
error:
error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
"__imp__Disasm" in Funktion
""private: void __thiscall BinaryBlob::callScan(unsigned int,unsigned int)"
(?callScan#BinaryBlob##AAEXII#Z)"
So to me it looks like the linker cannot find the implementation for the Disasm function.
If I comment the following line out it will compile without an error.
len = Disasm( &(this->disasm) );
My includes are like follows:
#include "stdafx.h"
#include "BinaryBlob.h"
#define BEA_ENGINE_STATIC /* specify the usage of a static version of BeaEngine */
#define BEA_USE_STDCALL /* specify the usage of a stdcall version of BeaEngine */
#include "BeaEngine.h"
Do I need to do something else besides including the BeaEngine.h?
Any help would be really appreciated!
What this says is that the compiler can see the .h file (it recognizes the .h file name) but is not linked to the library itself. I'm using VC10 but you should need to do something like
Property Pages,
General, then add the directory of the lib under Additional Library Directories
then
Input,
Additional Dependencies, put the name of the library mylib.lib
If it's a .dll either just put it with the .exe of your program or add the path of the .dll to your system PATH
Basically it's like a lawn mower: If it's getting air, gas and a spark it will run.
Air = .h file
Gas = linked to .lib or .dll (or other things on Linux)
Spark = Your program calling the lib
Related
I'm newbe with C++ please help me if someone can!
I've made a binary bigint object which work well.
I complied it to a static library and tried to include into an another program but it fails with errors like this:
combinations.obj||error LNK2019: unresolved external symbol "public: static void __cdecl BinBigInt::bifactorial(class BinBigInt const &,class BinBigInt &)" (?bifactorial#BinBigInt##SAXAEBV1#AEAV1##Z) referenced in function "unsigned __int64 __cdecl combi::nonrepCombination(char,char,class std::basic_string,class std::allocator >)" (??$nonrepCombination#D#combi##YA_KDDV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std###Z)|
If i copy paste the two code together everything is work well so the codes seems to be OK.
I read a lot of topics about the LNK2019 error and checked the compiler settings and Release vs. Debug version matching and so on but nothing helped.
At last I checked the symbols in the .lib file manually with MS dumpbin as guessed in some topic to check name manling problems but I found that a lot of (9) function name and all (7) of internally defined operators really not contained by the .lib file. (compiler just pop up 5 unresolved external symbol error those thats which I really tryed to used in the implementing file.)
It seems to be not just a name manling problem I absolutely not found those symbol names with dumpbin.
While lot of other functions which defined inside the object and operators (like Comparisson, bitwise etc.) which defined out of the object is contained by the .lib file.
I used: dumpbin /symbols binbigint.lib | findstr "function name" in a lot of version to check them.
I use Code::Blocks with MSVC2019 host and target both x64.
Someone have any guess what can couse that the lib didn't contain some symbols?
(The library code is about 3.000 row long so I didn't copy here...)
Well. I found the problem...
That was me... :(
Originally I've wrote the whole object declaration and definition inside the object scope in a .cpp file.
And it worked well. And I thought will be enough to delete the implementetion parts in the header and I can leaving the whole class code with the class header in the .cpp too and I forget include the .h to the .cpp so compiler not generated errors about it.
The fact that it works with Copy paste put me on the right track (that must be some problem with the .h+.cpp version) at the end.
Sorry for disturbing!
(This was my first class which I try to use as .lib)
Under Visual Studio (2017) I am trying to script a C++ program with Lua 5.3 but the linker does not find three function names referenced in my C++ source file:
unresolved external symbol _lua_close
unresolved external symbol _lua_createtable
unresolved external symbol _luaL_newstate
I took the C++ source from the Lua website.
I downloaded the Lua 5.3 dynamic library which does not come with an import library so I created the import library with the MSVC tools like so:
dumpbin /exports E:\Documents\Programmation\Lua5.3\lua53.dll
From the output of dumpbin, I copied the 146 names in a new file "mylua53lib.def" and ran lib to generate the .lib file like so:
lib /def:E:\Documents\Programmation\Lua5.3\mylua53lib.def /OUT:E:\Documents\Programmation\Lua5.3\mylua53lib.lib /machine:x86
The three function names that the linker does not find are indeed not appearing in the output of the dumpbin command.
A binary distribution of Lua intented for dynamic linking on Windows should come with two binary files:
a DLL file with the actual Lua code
a library file with the method stubs delegating to the DLL
Sometimes the library file will come with an .a extension, which is more common on Linux (as opposed to .lib on Windows). If it's a Windows build, though, you can simply pass that file as a linker dependency and it will work just fine. This question deals with differences between the two conventions.
As a side note, in order to make it work, if you create a C++ project in Visual Studio, and add a Source.cpp as it suggests by default, you'll still get unresolved externals. This is due to the fact that while the C sources compile as C++ code just fine, the linker will expect mangled names for the definitions of the C functions used. This can be prevented by either compiling the file as C code, or, preferrably, by telling it that the names from Lua headers should be unmangled in the linked library using extern "C":
extern "C" {
#include <lua.h>
#include <lualib.h>
#include <lauxlib.h>
#include <stdlib.h>
#include <stdio.h>
}
I am trying a very simple implementation of a C++/CLI wrapper to allow legacy C++ code to reference .Net code, as described here. I am getting stuck just trying to get my basic C++/CLI unmanaged (native) objects linked, without even including any managed/IL/.Net code.
My question is, following along with this basic setup and what I describe below, am I right to be very confused about these errors? Are there some considerations that I'm missing? Maybe the answer is that this should work, so it's not clear what's wrong. That's still helpful. A similar working example would be great.
Unresolved Symbol Errors
Error LNK2019 unresolved external symbol "__declspec(dllimport)
public: __thiscall Wrapper::Test::Test(void)"
(__imp_??0Test#Wrapper##QAE#XZ) referenced in function _main NativeApp
Error LNK2019 unresolved external symbol "__declspec(dllimport)
public: __thiscall Wrapper::Test::~Test(void)"
(__imp_??1Test#Wrapper##QAE#XZ) referenced in function _main NativeApp
I've reviewed related questions on SO without any luck. I've got my dll header included in the client C++ project, my project reference to the C++/CLI wrapper dll, and my define statements for import/export. My very simple code is shown below. I am not using any MFC. I am using VS2017. DumpBin.exe /exports shows export symbols that seem to match what the linker error says are missing.
1 0 000010D0 ??0Test#Wrapper##QAE#XZ = ??0Test#Wrapper##QAE#XZ (public: __thiscall Wrapper::Test::Test(void))
2 1 000010E0 ??1Test#Wrapper##QAE#XZ = ??1Test#Wrapper##QAE#XZ (public: __thiscall Wrapper::Test::~Test(void))
3 2 000010C0 ??4Test#Wrapper##QAEAAV01#ABV01##Z = ??4Test#Wrapper##QAEAAV01#ABV01##Z (public: class Wrapper::Test & __thiscall Wrapper::Test::operator=(class Wrapper::Test const &))
Here's the basic code...
NativeApp.exe (project)
NativeApp.cpp (File)
#include "stdafx.h"
#include <iostream>
#include "Wrapper.h" //From additional includes directory
int main()
{
std::cout << "Program Started" << std::endl;
Wrapper::Test shell = Wrapper::Test::Test(); //Use dll
std::cin.get();
return 0;
}
Reference to Wrapper
Wrapper.dll (Project)
Wrapper.cpp (File)
#include "Wrapper.h"
#pragma unmanaged
namespace Wrapper {
Test::Test() {
}
Test::~Test() {
}
}
Wrapper.h (File)
#pragma once
#ifdef WRAPPER_EXPORTS
#define WRAPPER_API __declspec(dllexport)
#else
#define WRAPPER_API __declspec(dllimport)
#endif
#pragma unmanaged
namespace Wrapper {
class WRAPPER_API Test {
public:
Test();
~Test();
};
}
I was under the impression that the project reference took care of any additional dependency settings behind the scenes. Apparently, that is not the case. The .lib file needed to be added as an additional dependency, as is described here. However, as described by this Microsoft document, everything worked without additional dependencies when I was using non /clr dlls, so I'm not sure why the additional dependency was only required for my CLR reference. Clearly, I need to read up on this some more.
In any case, my C++ client project requirements are listed below. I was missing the second requirement. Also, here is an example project that helped me diagnose the problem.
1.) Add project reference
2.) Add the .lib file as an `Additional Dependency.
[Optional] Use Additional Library Directories
3.) #include .h file in code where appropriate
[Optional] Use additional include directories
EDIT: Why the additional dependency was required, and alternative option
As noted above, I was getting hung up on why the .lib additional dependency was required for the /clr dll but not for the non-clr dll. The answer is because a /clr project is configured by default to ignore import libraries. So when the project gets referenced by another C++ project, the project reference ignores import libraries. Changing this setting (Linker > General > Ignore Import Libraries) to "No" in the /clr dll project solves the issue so that the additional dependency is not required and the project reference works the same as the non-clr C++ dll.
I am using Octave within MSVC 2010. First I downloaded Octave latest version at this link. After installing, I tried to run this simple code:
#include <iostream>
#include<octave-3.6.4\octave\oct.h>
#include<octave-3.6.4\octave\config.h>
#include<octave-3.6.4\octave\octave.h>
using namespace std;
int main (void)
{
std::cout << "Hello Octave world!\n";
system("PAUSE");
return 0;
}
Note that I added these links to my project as well:
C:\Software\Octave-3.6.4\include\octave-3.6.4\octave--->Includ. Dir.,
C:\Software\Octave-3.6.4\include--->Includ. Dir.
C:\Software\Octave-3.6.4\lib--->Lib. Dir.
C:\Software\Octave-3.6.4\lib\octave\3.6.4--->Lib Dir.
I also added 1 and 2 to Additional Inc Dir!!
C:\Software\Octave-3.6.4\lib\octave\3.6.4--->Additional Lib. Dir in Linker.
First, I got this error that it cannot find math.h in Program Files while this file was in my Program Files (x86). So, I changed it to: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h and it solved this error. However, now I get this error:
error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall octave_value::~octave_value(void)" (__imp_??1octave_value##QAE#XZ) referenced in function "public: void * __thiscall octave_value::`vector deleting destructor'(unsigned int)" (??_Eoctave_value##QAEPAXI#Z)
It is not sufficient to add the library path to the project.
You have to add the library name(s) (including .lib) to the "Additional Dependencies" in the Linker/Input tab.
Edit
To verify what library has been searched you can enable the Linker/General/Show Progress option. Then you can see in the Build Output what library has actually be used in symbol search.
Edit
Your example code doesn't show any instance of an array of octave_value instances. So it's a bit surprising that you need to link with any library with the code you've shown. But anyway you want to have these externals resolved.
If there is no other resource (manual, ...) you should detect where the octave_value class is implemented. This can be a static library or a DLL.
You can detect the DLL implementation with a dumpbin /exports on the DLLs. In that case you need the corresponding import libraries. The LIB should have the same base name as the DLL. Verify that you have added that dependency and how the linker searches this library for symbols.
The name of the symbols __imp_??1octave_value##QAE#XZ indicates that it should be in a DLL. But since you have a problem you might want to search LIBs too.
You can detect the LIB implementation with a dumpbin /symbols. In that case you have to add the LIB directly. Again verify it with the Build Output.
The dumpbin output will probably very verbose. You should use either findstr to limit the output or redirect the output to a file and search the symbols with an editor of your choice.
Search for ocatave_value. If you find a different decoration of the constructor and destructor you might have missed to set an option. A preprocessore directory could be used to define how the library is use. E.g. if you find octave_value::octave_value without the __imp_ prefix you have accidentily compiled for a DLL version altough the class is implemented in a static library. In that case, read the manual and ask at the octave mailing list forum or whatever.
I have a file foo.h that has various declarations for functions. All of these functions are implemented in a file foo.dll. However, when I include the .h file and try to use any of the functions, I get the error:
bar.obj : error LNK2019: unresolved external symbol SomeFunction
so obviously the function implementations aren't being found.
What do I have to do to help the compiler find the definitions in the DLL and associate them with the .h file?
I've seen some stuff about __declspec(dllexport) and __declspec(dllimport) but I still can't figure out how to use them.
You should have received at least three files from the DLL owner. The DLL which you'll need at runtime, the .h file with the declarations of the exported functions, you already have that. And a .lib file, the import library for the DLL. Which the linker requires so it knows how to add the functions to the program's import table.
You are missing the step where you told the linker that it needs to link the .lib file. It needs to be added to the linker's Input + Additional Dependencies setting of your project. Or most easily done by writing the linker instruction in your source code:
#include "foo.h"
#pragma comment(lib, "foo.lib")
Which works for MSVC, not otherwise portable but linking never is. Copy the .lib file to your project directory or specify the full path.
I just had a similar problem. The solution turned out to be that the DLL was 64 bit, and the simple app using it was 32. I had forgotten to change it to x64 in the Configuration Manager.
You need to specify in front of function definitions __declspec(dllexport) keyword at the time of building the dll
You need to import or load the .dll file into process memory.
You need to acquire the address of function you want to use from that dll.
Some useful links to get started:: MSDN Documentation, SO, Random