Dynamic linking in Visual Studio - c++

I have to link dynamically with OpenSSL libeay32.dll.
I'm writing native c++ console application using Visual C++ Express 2008.
I'm including a header evp.h from OpenSSL distribution. Building and...:
error LNK2001: unresolved external symbol _EVP_aes_256_cbc
error LNK2001: unresolved external symbol _EVP_DecryptInit
error LNK2001: unresolved external symbol _EVP_CIPHER_CTX_init
How to make calls to libeay32.dll methods? I don't know where to specify it's filename

There is probably a .lib file you also need to add to your compiler's linker input. Check the documentation for the library you're using.

Try using Win32 API's LoadLibrary function, the following link might be of some help :example

if your application need to be able to run without the existence of OpenSSL, use dynamic linking with explicit run-time linking and handle the cases when the DLLs are not around (e.g. by changing your application's behavior / switching to other libraries).
I recently found a nice examples on this:
Google Gears WinCE Geolocation API
itsutils
if your application may only run if the OpenSSL exist in the environment (or you ship the DLL), use implicit run-time linking.
For MSVC, the simplest is to add #pragma comment(lib,"libeay32.lib") in your source code (You will probably need the .lib stub to be produced by the same compiler you use)
if your application need to be independent of the environment. Link OpenSSL statically (also uses .lib).
Note that there are 2 kinds of .lib. The first is used for dynamic but implicit linking, second is for static linking. The one for dynamic implicit linking contains stubs that load the DLL for you whereas the one for static linking contain the actual implementation.

In the project properties, configuration properties, linker, input - add the library name under "additional dependencies".
[Note, this will actually STATICALLY link with the library. If you truly want to load the library dynamically you will need to call LoadLibrary() on the DLL and then get function pointers for the functions you need using GetProcAddress().
See for example
http://msdn.microsoft.com/en-us/library/ms886736.aspx
and
http://msdn.microsoft.com/en-us/library/ms885634.aspx

If you are calling a method from the dll, you can use explict dynamic linking method.
Mistake: you are including a header evp.h from OpenSSL distribution dll to your prohject
As you are linking dynamically, no need to include .h from A DLL to your project.
You can call by following method:
LoadLibrary("libeay32.dll"); /* syntax: */
Declare a function pointer pointing to the function you want to call.
For eg.
Let your libeay32.dll has an exported function: int add(int x, int y);
Then to call it in your project declare a function pointer and then call the method add as follows:
typedef int (*AddfnPtr)(int num1, int num2);
int num1 = 2, num2 = 3 ;
HMODULE handle = NULL;
handle = LoadLibrary("libeay32.dll");
if (handle != NULL)
{
AddfnPtr addfnptr = (AddfnPtr)GetProcAddr(handle, NULL);
if (addfnptr != NULL)
{
int res = addfnptr(num1,num2);
cout << "res = "<<res;
}
}

Related

Getting symbols for explicitly loaded DLL from the application

I am modifying my application so that it can explicitly load a DLL (through the Windows API) and call some functions from the DLL. But I need to be able to call some application's functions from the DLL too. I can only provide header files of the functions to the DLL. But I am getting the LNK2019 'unresolved external symbol' error.
Is my idea even feasible?
So you found a way to do this, however you should also ask yourself whether you should do it.
If your executable depends on the DLL then the DLL should not depend on that executable. This is not just a question about principles but also about avoiding future problems.
The way you could achieve the calls from the DLL to the executable is to define a function-pointer type and a setter in the DLL's headers:
typedef void aCallbackType(void);
void setMyCallback(aCallbackType* Cb);
In setMyCallback the DLL stores that function-pointer to later call it.
Then the executable can define a function and give that to the DLL:
void myCallback(void) { }
void myProgram(void) {
setMyCallback(myCallback);
}
Thank you #AdrianMole for solving my problem! To resolve the external symbols in the DLL you'll need to create an import library of the EXE. In Visual Studio 2017, this can be done by going to the project properties. Go to Linker → Advanced and set the Import Library setting to the path and name you want. (For example: $(TargetDir)\myimportlibrary.implib). Then, go to the the DLL project properties → Linker → Input and add the import library to the Additional Dependencies setting.

trouble linking to de-decorated DLL names in C++ (32 bit) in Visual Studio

I have a library of DSP functions in C++ and I want to link to them dynamically at run time. I am using the PDLL.h method to wrap my classes (for example FFT) into C-style functions and load them load on the fly in other C++ applications. I want to use these functions in .NET applications and COM components, so I have to use __stdcall which decorates the names in 32 bit builds.
In order to undecorate the names, I am using the trick mentioned here: C++ DLL Export: Decorated/Mangled names (wqw's answer, 2nd down). So for example, in my library's .h file I have declared my wrapped functions so:
#pragma comment(linker, "/EXPORT:DoFFT=_DoFFT#12")
RTLIBS_API DoFFT(FFT* x, DOUBLE* pdDataIn, DOUBLE* pdDataOut);
This does indeed work, and when I look into the dll with dependency walker, I see that there is both an entry for DoFFT and _DoFFT#12.
The problem that I have is that when I try to build a project that links to this library (dynamically, at run time, not using the .lib file at all) I get linker errors for all the functions in my dll, i.e.:
Error 31 error LNK2001: unresolved external symbol _DoFFT#12
I don't understand why this is happening. First of all, the symbol _DoFFT#12 does exist (according to dependency walker) and second of all, why is the linker looking for it in the first place? I am linking to it at run time, not at compile time so how does my project even know about this symbol?
All the functions are declared with the same chain of macros that reduces to (e.g.):
extern "C" __declspec(dllexport) int __stdcall DoFFT(FFT* x){...}
Nothing having to do with the library is declared on the client side.

How to build with required `.dll` in Windows 10 Visual Studio

I'm trying to build a project. I have a.lib file that I need to use in my project. I know that there are two ways to use this lib:
add it using #pragma comment(lib, "a.lib")
add it to linker dependencies Configuration Properties -> Linker -> Input -> Additional Dependencies
Now, a.lib uses StackWalk64 function DbgHelp. This library is supplied as DbgHelp.lib and DbgHelp.dll. I know that I can use it as a lib using two ways listed above. But what if I don't want to include it into my project and want to use DbgHelp.dll, how can I do that in Visual Studio?
If you want to call a function that is within a DLL, but don't want to link to the LIB file that imports these functions for you, then you can use LoadLibrary and GetProcAddress. (Though if you have the import library and can link to it, why do you want to load these functions manually?)
IF YOU HAVE THE DbgHelp.lib IMPORT LIBRARY, USE IT! LOADING FUNCTIONS MAUNALLY IS ERROR-PRONE IF NOT DONE RESPONSIBLY. USE WITH CAUTION!
// Type definition for a function pointer that can call the function
typedef BOOL (WINAPI *StackWalk64_func)
(
DWORD,
HANDLE,
HANDLE,
LPSTACKFRAME64,
PVOID,
PREAD_PROCESS_MEMORY_ROUTINE64,
PFUNCTION_TABLE_ACCESS_ROUTINE64,
PGET_MODULE_BASE_ROUTINE64,
PTRANSLATE_ADDRESS_ROUTINE64
);
// Within a function . . .
HMODULE hDbgHelpDll = LoadLibrary(TEXT("DbgHelp.dll"));
if (hDbgHelpDll == NULL)
{
// handle error and return
}
StackWalk64_func funStackWalk64
= (StackWalk64_func)GetProcAddress(hDbgHelpDll, "StackWalk64");
if (funStackWalk64 == NULL)
{
// handle error and return
}
// funStackWalk64 is valid and ready to use
Now you can call funStackWalk64 like the function StackWalk64, and pass the function pointer around the place. When you're done using the library, you should free the module handle:
FreeLibrary(hDbgHelpDll);
Please read up: http://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/
Implicit Linkage with an import library (using .lib)
In this case the static-library is an "import library", which automates the process of determining the effective functions in the DLL. This is called implicit dynamic linkage.
Explicit Linkage
If you don't want to use the import library you have to determine all functions by yourself, create corresponding pointers to the addresses of the procedures and use them after that.
Usually there's some InitDLL() function in your client code, which does this.
See: https://msdn.microsoft.com/de-de/library/64tkc9y5.aspx
The "GetProcAddress"-function can be used to obtain a handle to the function and call it.
This is called explicit dynamic linkage and requires also the calls to LoadLibrary() and FreeLibrary() on Windows.
More Info: http://www.equestionanswers.com/dll/what-is-implicit-and-explicit-linking-in-dynamic-loading.php
Explicit Linkage on Linux
For linux/unix things work differently. If you want to read up: http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Usually (and in Visual C++ specifically,) the lib file that comes with a dll is what is called an "import library". It means that the library has no actual function bodies in it; it is just there to appease the linker and instruct it to generate an EXE (or DLL) that would use the first dll at load time.
It is so in this case too. Since you don't have access to the source code for DbgHelp so that you can build it as a real static library, you need to make do with the small import library at link time and the dll file at load/run time.
Note: the whole linking and dynamic linking concepts and mechanisms are obviously a lot more complex than what I have room here to discuss. So, the explanation above is quite narrow and specific to your question.

How to call a function in DLL defined another project

I'd like to call a function in DLL (lets say foo function defined in a X project ). So DLL never knows the exact implementation of this foo function. But later I want to use this DLL in the X project (that contains the foo function).
When I try to compile the DLL, linker gives the "Unresolved external" error. How can I tell the compiler that foo function is defined in another project.
For example;
foo.cpp in DLL project
extern void foo();
void DLLFunction()
{
foo();
}
impl.cpp in X project
void foo()
{
//Do something
}
And if I can compile foo.cpp in the DLL project, I will use this DLL in the X Project.
If I understand the question correctly, you want to have a DLL, which imports a function from the executable it is linked against.
In general it is possible, but tricky, so first thing you should consider is if you really need to do that or if you can change the DLL function to e.g. accept a function pointer (which then does not require to import a symbol from executable into the DLL).
It is still possible to use symbol from executable in the DLL. It is possible to export a symbol (function) from the executable and use in the DLL (normally the same way you export from DLL, e.g. "__declspec(dllexport)" on Windows). However the tricky part is, that by default you need the dependency to link the particular object, i.e. in this case you'd need the DLL to link the executable and the executable to link the DLL, which is a cyclic dependency.
So you need to break the cyclic dependency. There are some possibilities:
Loading the DLL dynamically as a plugin - using dlopen() on Posix and LoadLibrary() under Windows. Then you do not need the DLL to build the executable, and you can link the EXE providing the symbol with the DLL.
The other way around - on Windows, you can dynamically import the exported symbol from the executable into the DLL (GetModuleHandle(), GetProcAddress()).
Allowing the DLL to be build with unresolved symbols. Then you build the DLL with the symbol unresolved, and build the EXE against the DLL. When executed, the executable will load the DLL and will provide the symbol.
To allow building the DLL with unresolved symbols:
In Linux GCC this is the default behaviour (shared objects do not enforce symbols to be resolved), unless you build with "-Wl,--no-undefined".
In Windows MSVC, you can ignore the unresolved symbols when building the DLL by providing the "/FORCE:UNRESOLVED" parameter to the linker. Note that on Windows/MSVC, after you build the EXE .lib file, you then need to rebuild the DLL again against that file to import the symbol.
What you can do is to instead of writing extern, you can load the DLL dynamically
e.g.
auto hd = LoadLibrary("YourDll.DLL");
typedef void(*userfunc)() ;
userfunc p = GetProcAddress(hd, "foo");
p();
Alt. link with the .lib file created when you built the DLL
discalimer: code for cleanup, error checks etc omitted.
If you are using a recent version of the Visual Studio IDE, you can simply reference it - Visual Studio will take care of the rest. To do that, right click on the "References" entry in your Solution Explorer for the project you want to link against your DLL. From there, select the other DLL project in your solution:
This will take care of all the linking required and saves you the trouble of changing your project settings if you rename your projects or change the name of the output-files.
If you don't have the other project in your solution you will have to stick with the regular static linking procedure:
Project Settings -> Linker -> General -> Additional Library Directories
Project Settings -> Linker -> Input -> Additional Dependencies
If you want to dynamically link against the DLL at runtime, you can use the method described by Andreas K.

C++ static library using functions defined in another cpp project

I am working on a VS 2012 project and i am using an already compiled static library (that was compiled in VS 2013). The library references the "vacopy" method that is VS 2013 compatible but not found in VS 2012.
When I compile my cpp project, I get the linking error : error LNK2019: unresolved symbol __imp___vacopy
My first reflex was to add the declaration and definition of va_copy in my project, so I included the following:
in a header file :
void va_copy(va_list dest, va_list src);
in a cpp file :
void va_copy(va_list dest,va_list src)
{
dest = src;
}
But this didn't resolve the problem, I still get the same linking error.
Thanks in advance for your answers.
You basic problem is that the library was compiled to link with standard libraries in a DLL (thus the __imp__); you application is probably set differently (to grab standard calls from a statically linked in library).
You either have to match your compiler settings (in this case project properties -> C/C++ -> Code Generation section) where you can specify to use DLL or static options.
It's often worth checking if there is a way to specify to the include files which version of the link you need - some libraries (CURL for example) allow you to define compiler predefines to control exactly which functions are linked to.