I'm writing a dll as a mod for Skyrim, however I need to use an external library as well. The library I need is the curl library for C++ (curlpp). Skyrim will only load the one DLL I create, therefore I need to have the entire library be compiled into the DLL file along with my code. I've never done this before, so I'm kind of lost on how to do this. Could I just copy the files from the curlpp library into my project?
If anyone could clarify the process needed I'd be very grateful.
So to recap, I'll have my own code, and the library. Those 2 should be merged into a single DLL when compiling.
Thanks!
You could include the libcurl library code directly into your DLL, as libcurl is open-source.
Or you could compile libcurl into its own DLL (or find a 3rd party precompiled DLL) and have your DLL statically link to it. That way, if libcurl fails to load at runtime, your mod DLL will also fail to load, which Skyrim can detect and handle as needed.
Related
I have a C++ header file and the corresponding static library (.lib file). No source file.
The code comprises several classes, each with functions of its own.
I would like to be able to call these functions from MATLAB.
Would anyone be kind enough to point me in the right direction? Examples would be appreciated.
Thanks.
EDIT: Would it be a good idea to write a DLL to act as an interface between the static library and MATLAB? Then I can access the functions in my static library from the DLL and use calllib to access the DLL from MATLAB.
If so, how would I call the class member functions in the static library from a DLL?
Update
So I've decided to write a DLL to which I will link the static library and call the functions from MATLAB through that using calllib
The problem is, the static library is already compiled and I do not have the source. I try to link the .lib file (presumably built using Visual Studio) and build my DLL using MINGW32 but this doesn't work possibly due to (lack of?) interoperability of libraries created by different compilers.
This is the MinGW command I use to link: g++ -c -o -DBUILDING_INTERMEDIATE_DLL intermediate_dll.cpp -TaccClient.lib
intermediate_dll.cpp is the source file for my DLL and TaccClient.lib is the static library I'm using.
Does anyone have any suggestions as to how this could work, or will I have to wait and try it on visual studio later?
MATLAB offers MATLAB coder functionality that allows you to create MEX files from your C/C++ source and library files. There is also an option to called C shared libraries when building the MEX file for your application. I have used SIMULINK (with SIMULINK Coder) and Embedded Coder to do my library linking and it helps you to do it via GUI, so very neat job. However, you can still do it with MATLAB as long as you have a supported C/C++ compiler.
Using the C shared library option, you should be able to load, call, view the library and functions. For more details on what other functionlities are available, see this - http://uk.mathworks.com/help/matlab/using-c-shared-library-functions-in-matlab-.html
A similar question was answered here. May be you will find it useful?
I have created test C++ static library in VS and I am using boost in that.
Now this static lib is used/linked in DLL I have created. Now I want to link this DLL in a c++ console application.
Static lib and DLL both compiles fine. When I am using this dll in console application, I am getting error in static lib's header file that can not open include file #include "boost/config.hpp"
I copied static lib's header and dll's headers in console application and linked through properties/linker/additional library directores
I really dont want any user who are using my dll to link with boost and all. I just want to supply dll and they should be good to use it.
Please guide me. I am dealing with DLL and static lib. for the first time.
So If I include all boost headers in my application, it should be good to use. Is there any other solution?
The header files from your static library are including boost. When you include these in your application, the compiler is looking for the boost includes as well. If the boost declarations are not a part of your library interface, then these includes need to be moved out of header files referenced by your application.
I really dont want any user who are using my dll to link with boost and all. I just want to supply dll and they should be good to use it.
That's pretty much tough, not least because most of Boost is header-only.
At the moment I have an application and a (static) library, both written in Qt. As build system I use cmake. I link the library with target_link_libraries to the executable and everything works fine (and I have one file/executable).
But now I want to use a shared library. Creating a shared library with add_library and the keyword SHARED works, but I am a bit confused about the way, how to load a shared library. I saw two "ways":
Write a library and use Q_DECL_EXPORT / Q_DECL_IMPORT. They load the library with QLibrary and use a typecast to resolve all (C) functions
Write a library and include the header file in the application. The shared library is "passed" to the executable with the cmake command target_link_libraries. They don't use QLibrary to load the library.
Now I have a few questions:
What is the common ("normal") way to load a shared library ? Export all C++ methods to C functions with __cdecl (Way 1) or include the header file (Way 2)? Other solutions?
Related to way 2 (Include header) - how is the library loaded ? By the operating system ? If I move the library, the application cannot find the library -> Library loaded at runtime ?
Is there a way to load a library without including a header or use it at compile time (Load library at runtime)? I read there is a way, but it isn't that easy
I hope that my questions are clear and not "noobish", otherwise please write a comment
I guess the second way is more common, though I met both.
In second way library is loaded by os on application startup. If os cannot find library - the application won't start.
No matter which method you are using, you need to know functions' semantic. This means you will include header, which contains them, this way or another.
Also Qt gives you another way to load a library in runtime, using plugin method: link
This question is regarding dynamic linking of libraries and usage of dynamic linking of libraries in application.
For example we are devloping an application using C++ using Visual studio environment.
Here for include header files we specify in Additional Include Directories, and
in Additional Dependencies: Mylibrary.lib
in Additional Libraries Directories: We specifies path of libraries
And in Windows we also have "LoadLibrary" API which is used to load dynamically linked ibrary.
My question is
when we include dll in Additional dependencies libraries why we should use "LoadLibrary" API?
When we should use "LoadLibrary" API?
Thanks!
LoadLibrary lets you continue program execution if the dll is not on the running machine. It returns an error status that can be checked and execution can be continued.
Also, linking lets you do stuff like use classes from the other binary & others. LoadLibrary only lets you find functions via GetProcAddress.
Imagine that you have a software that for example needes at a determined time to convert
Internet network address into strings.
On windows vista or later you can use the "InetNtop" function that is also able to deal with ipv6, but if you link directly to the DLL your program will no work on lower OS (ex: windows xp).
So the best solution would probably be making 2 DLL's one that used "InetNtop" and another that used for example "inet_ntoa".
Then your "main" program would do at runtime a LoadLibrary of the "InetNtop DLL", or the "inet_ntoa DLL", according to the OS that he his installed.
You asked that you can include dll in Additional dependencies libraries, and then why to use loadlibrary.
First lets clear the understanding:
While linking statically, A programmer is needed to add the .lib file to
Additional library dependency, which is linked to the caller program at compile time,
However, Dlls are loaded dynamically, hence you need not to add dlls in Additional library dependency when you are using LoadLibrary ie; if you are linking the Dll explicitly you are not needed to give your dll path in Additional library dependencies.
Please note:
using LoadLibrary you will be able to Get the Dll handle, which you can call the exported function using GetProcAddress.
refer:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
I'm a little confused by what I've learned today. I hope somebody can help me out.
I understand the concept of dynamic and static linking, but the problem is as follows. On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct? In other words, gcc or g++ must have .lib files available at compile/link time, and be able to find .dll files at runtime. Please correct any wrong assumptions here.
However, I'm splitting a few of my source files in my small application away because I want to make them a library. When I run g++ on my object files, with the -shared option, this basically creates a shared library (.so)? This is where the confusion arises. The same so file is needed both at link time and runtime? I have trouble understanding how I need it in the -L/-l option at link time but it still needs the file at runtime. Is this actually the norm? Is a dll fundamentally different?
Finally, a final question. Take a library like boost on Windows. I built boost according to the instructions. In the end, the stage/lib directory contains libraries in a repeating sequence of name.a, name.dll.a, name.dll. What is the purpose of this scheme? I know I need the dll files at runtime, but when I use the -L/-l option at link time, what files is it using THEN?
Sorry if this is really scattered, but I hope someone can help clear this up. Thanks a lot!
On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct?
Yes and no. That is one way that DLLs work on Windows, but it is not the only way.
You can load a DLL manually, using Win32 API calls. But if you do, you have to get function pointers manually to actually access the DLL. The purpose of the import library (that static library you're talking about) is to do this automatically.
The nice thing about doing it manually is that you can pick and choose what DLLs you want. This is how some applications provide plugin support. Users write a DLL that exports a well-defined set of API functions. Your program loads them from a directory, and they bundle the function pointers for each DLL into its own object, which represents the interface to that plugin.
GCC works the same way, on Windows. Building a DLL produces a DLL and an import library. It's a ".a" file instead of ".lib" because of the compiler, but it still does the same thing.
On Linux, .so files are a combination of the .dll and the import library. So you link to the .so when compiling the program in question, and it does the same job as linking to the import library.
It's just two ways of giving infos at compile time about the shared library. Maybe a comparison would explain it better ?
In Windows, it's : "You will use a shared library (.dll) and here (.a or .dll.a) is the manual on how to use it."
In Linux, it's :" You will use a shared library (.so) so look at it beforehand (.so) so you'll know how to use it."