I have a simple class (the analog clock from the Qt examples) that I want as a test to compile into a shared library. So what I want in the end is to have a .dll file and a .lib file.
What I did was simply create a new project, add the analog clock header and source file and then configure TEMPLATE = lib in the pro file.
Yet this only creates a .dll file and the article I found on the docs is not very helpful.
Does anyone know how can I solve this, and end up with both the dll and lib files?
EDIT 1
After doing this
#if defined(TEST)
#define AnalogClockPlug Q_DECL_EXPORT
#else
#define AnalogClockPlug Q_DECL_IMPORT
#endif
and then simply adding AnalogClockPlug in front of my main class and defining TEST in my pro file, qt generated a lib file.
Yet I am not sure I understand why exactly, or even if it is correct.
Q_DECL_EXPORT is just the same (under Windows) as __declspec(dllexport) pragma. It makes all the methods of your class to go to the dll 'exports' table (a special section in dll binary file).
Lib utility just reads the dll exports, and produces what is called 'the import library' - it's not like a usual static lib, containing actual code, but just a bunch of records stating that 'such procedure name' is to be found in 'such dll name'.
If you don't have that pragma, your dll exports table is empty, and lib utility refuses to output empty lib file. That's all.
To make a static library you will also need to add
CONFIG+= staticlib
to the .pro file
Related
I’m currently having some problems trying to implement an integration with a Verifone PoS.
The bank we are working with provided us with one .dll file, one .h file and one .hpp file.
I’m usually a Java or PHP developer, so for the last days I consumed everything I found on the web about DLL files and how to use them, but none seemed to work so far. I got a lot of errors, many of them being something like “invalid dll”.
I found on the web that alongside a dll file there should have been a .lib file. I asked the third party about this, but apparently
There is no .lib file. The .dll file contains all the required info for an integration
From their documentation of library I found this:
The form of the supplied binary is a dynamic library. By its nature, a dynamic library allows for easier updates and corrections, not requiring recompilation or relinking of the client (calling) code, as long as the procedures prototypes (function parameters and return types) remain the same.
The language used for the library implementation is C++.
To access the functionalities implemented in the library binary, a C-style header interface is provided. This is comprised of the function prototypes available to be called as well as the types of the result-structures through which the returned data needs to be interpreted to make sense for the previously accessed functionality (the specific requested transaction).
So yeah, the .h file includes only the data types, and the .hpp file contains some declarations that looks like this:
extern "C" __declspec(dllexport) bool doSomething(int param);
Also in their documentation there is an example of how an implemetation should look (and it is fairly simple):
bool someVar = doSomething(1);
It looks like those functions can be called as simple as that, but they cannot. If I try to do that I get an “undefined function” (or similar) error.
At this point the only thing that seemed to have somehow worked (maybe) is loading the DLL with the LoadLibrary function. But besides the fact that whatever function I try to call, with whatever parameters, it returns false, it seems kind of wrong that I do not use the .hpp file at all.
So here we are. How I should aproach this? Is there a way to load the DLL and use the provided HPP file as function definitions? If not, is there another way beside LoadLibrary + GetProcAddress combo to do this?
Thank you!
I'm assuming the dll is a native dll, not a managed assembly (.net dll).
Usually, the dll author adds a preprocessor definition to the build system, like DLL_EXPORT. So if the author compiles the dll, the import library (a small .lib file) will contain all functions that used the DLL_API macro. Then the author can ship the very same header to a user. Because that user won't have the DLL_EXPORT macro defined, DLL_API will resolve to a dllimport, which basically says that the annotated function is defined in the import library.
Such a header might look like this (the whole #if condition is usually in its own header file which is then included in all headers that export functions):
#ifdef DLL_EXPORT
# define DLL_API __declspec(dllexport)
#else
# define DLL_API __declspec(dllimport)
#endif
extern "C"
{
void DLL_API SomeFunction(int x);
void DLL_API AnotherFunction(int x);
}
If the author builds the project (in msvc) the compiler will generate the dll file and a small .lib file, which is the import library. This lib will essentially do what you have to do now: calling LoadLibrary and GetProcAddress to resolve all the functions that have been annotated with __declspec(dllexport).
The following part is a bit speculative and I'm guessing a bit here.
All __declspec(dllimport) does, is tell consumers that this dll contains those functions. But the linker has to link a declaration to its definition (implementation) so the function must be defined somewhere at compiletime. And that place is the import library (.lib). If you don't link with the import library, you will get a linker error when you build your project.
This means simply changing the dllexport to a dllimport won't solve your problems. Without an import library your only option is to load the dll manually with LoadLibrary and search for each function.
If I were you, I'd ask the author for an example project that uses the dll. AFAIK, the only ways to use a native dll is either by linking to an import library or by loading everything manually.
Manually generating the import library from the dll
I've tested this to make sure it works.
First of all, fix the header file to either use the macros like I did in the example above, or just use dllimport directly.
Second, open the developer command prompt for VS and follow the steps from this answer. Make sure to use the correct file names and target architecture (x64 or x86). Now you should have a .lib file.
Thrid, add the lib to your project.
Add the directory of the lib (place it somewhere close to the project so you can use relative paths). Open the project properties and follow the steps in this image:
Make sure that Configuration and Platform are correct (you probably want it like in the image). You can also use relative paths. Click on the Macros button to see all predefined paths available to you.
Add the lib to the linker dependencies:
Put the header somewhere in your project where you can access it.
Now you can simply include the header anywhere in your project and use the functions declared inside it. But note that the dll file has to be placed somewhere where LoadLibrary can find it. Preferably this is the same directory where your project's executable is located.
Bonus facts
The definition file (.def) is actually very simple. The def file for my sample code above is:
LIBRARY MyLibrary
EXPORTS
AnotherFunction
SomeFunction
If I remove the extern "C" block around my declarations, my function names will be mangled and the def file looks like this:
LIBRARY MyLibrary
EXPORTS
?AnotherFunction##YAXH#Z
?SomeFunction##YAXH#Z
If you put those functions inside a namespace (for example FooSpace), that namespace name will also be part of the function name:
LIBRARY MyLibrary
EXPORTS
?AnotherFunction#FooSpace##YAXH#Z
?SomeFunction#FooSpace##YAXH#Z
Note that all extern "C" entities will ignore namespaces, meaning all extern "C" functions, variables, types, ... will be put into the global namespace, no matter if you define them inside a namespace or not.
These are also the names that you'd have to pass to GetProcAddress if you did it manually.
I want to create a dll that exports a function and a struct. I went through the walkthrough and here is what I have:
Project myDll: the_dll.h
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
typedef struct MyStruct
{
bool b;
} MYSTRUCTTYPE, *PMYSTRUCTTYPE;
typedef const MYSTRUCTTYPE *MYCSTRUCTTYPE;
MYDLL_API bool dllF();
Project myDll: the_dll.cpp
#include the_dll.h
bool dllF() { return true };
In the Preprocessor definitions of the myDll project, I define MYDLL_EXPORTS
In Linker -> Advanced -> Import Library I see $(OutDir)$(TargetName).lib
Yet there is no lib generated, only dll and pdb
Intellisense shows MYDLL_EXPORTS to be __declspec(dllexport) and the dllimport portion is grayed out... So I must be exporting...
I have included the dependent header file, and set the additional library directories and additional include directories, as well as dependent libs, in the caller project. But... in the absence of the lib...
The project that requires the functions from this dll gives unresolved external symbol error.
How can I make my dll create a lib ? What am I missing ? (Or... how can I use its functions without linking to a lib and include a header ?)
Note: I assume the structs and typedefs do not need to be exported... true ?
Update: as I wrote in comment, the project did create a lib when I imported it into a different solution and erased all the debug folders... I have been "Build -> Clean Solution" between tries but I suppose something did not get cleaned ...
So the true reason for not getting a lib created was (my guess) that, while experimenting with the code and before adding the definition for MYDLL_EXPORTS, files where created that did not get cleaned... I will always delete the build folders before trying again, in the future.
I checked with a small test project in VS2013. It produced .lib files for both my DLLs in the Debug directory. This means that if the setup is not screwed up, using default settings you should have implib after building the DLL.
In fact, you need .lib file only if you want to distribute your dll to customers. If you want to use this dll in the same solution by other projects, do the following:
Select project where you want to import functions.
On the top menu click PROJECT->References....
Click button "Add New Reference" at the mid bottom.
Select dlls that you want to import from.
Close all dialogs with OK.
Rebuild your solution.
Structures cannot be exported. They are communicated to other binaries using header files. You can export only function entry points (including class member functions) and static data fields. You should include your header both into your dll code and and all applications that use your DLL. The #ifdef MYDLL_EXPORTS has exactly this purpose.
I try to make simple dll project in Visual Studio 2013 like in http://www.itcsolutions.eu/2009/12/10/how-to-create-a-dll-dynamic-link-library-in-c-as-visual-studio-2008-project/
But when i try to build solution it falls with an error:
error LNK1104: can not open file "D:\prj\dlltest1\Debug\dlltest1.lib" D:\prj\dlltest1\ConsoleApplication1\LINK ConsoleApplication1
But dlltest1 is dll-project. Why there is an .lib file?
Updated: The reason why no libs are generated because you have no symbols exported. I just checked your code.
You should have a *.h file define exported symbols like this.
#ifdef WIN32PROJECT1_EXPORTS
#define WIN32PROJECT1_API __declspec(dllexport)
#else
#define WIN32PROJECT1_API __declspec(dllimport)
#endif WIN32PROJECT1_API int fnWin32Project1(void);
When you created a DLL project, it has some exported symbols other project can use. These symbols' name and offset are stored in *.lib file. *.lib file is created with *.dll files, both of them are put in the output directory.
In the link stage of you ConsoleApplication, the linker try to find the symbols from all your referenced libs (defined in project property) and store these symbols' offset and source dll in output exe file.
You can change the libs settings in Property->Linker
Wikipedia says:
DLL compilation will produce both DLL and LIB files. The LIB file is used to link against a DLL at compile-time; it is not necessary for run-time linking.
The code within your application determines whether compile-time or run-time linking is required:
If you access your DLL functions like
__declspec(dllimport) someFunction(int firstArg, int secondArg)
then your compiler will require both the .dll and the .lib file for linking to the shared library, but during execution, only the .dll will be required.
If you however make use of the DLL functions LoadLibrary, GetProcAddress and FreeLibrary, the .lib will not be required for linking.
I want to bring a .dll dependency into my Qt project.
So I added this to my .pro file:
win32 {
LIBS += C:\lib\dependency.lib
LIBS += C:\lib\dependency.dll
}
And then (I don't know if this is the right syntax or not)
#include <windows.h>
Q_DECL_IMPORT int WINAPI DoSomething();
btw the .dll looks something like this:
#include <windows.h>
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call,
LPVOID lpReserved)
{
return TRUE;
}
extern "C"
{
int WINAPI DoSomething() { return -1; }
};
Getting error: unresolved symbol?
Note: I'm not experienced with .dll's outside of .NET's ez pz assembly architechture, definitely a n00b.
Your "LIBS +=" syntax is wrong. Try this:
win32 {
LIBS += -LC:/lib/ -ldependency
}
I'm also not sure if having absolute paths with drive letter in your .pro file is a good idea - I usually keep the dependencies somewhere in the project tree and use relative path.
EDIT:
I suppose that something is wrong in your dll, i.e. the symbols are not exported correctly. I always use template provided by QtCreator:
Inside dll project there is mydll_global.h header with code like that:
#ifdef MYDLL_LIB
#define MYDLL_EXPORT Q_DECL_EXPORT
#else
#define MYDLL_EXPORT Q_DECL_IMPORT
#endif
Dll project has DEFINES += MYDLL_LIB inside it's pro file.
Exported class (or only selected methods) and free functions are marked with MYDLL_EXPORT inside header files, i.e.
class MYDLL_EXPORT MyClass {
// ...
};
This is possible if the DLL contains files with a "C" linkage (i.e. no C++ class decorations) and if you have a header file and a .def file for the DLL. If you do not have a .def file you can create one easily by downloading the dependency walker tool from http://www.dependencywalker.com/ to get the list of exported symbols; you can save the output of this tool as text, then extract the names. You then create a text file called mylibname.def that holds:
LIBRARY mylibname
EXPORTS
FirstExportedFunctionName
SecondExportedFunctionName
...
LastExpertedFunctionName
Then you run dlltool (in MinGW\bin):
dlltool -d mylibname.def -l mylibname.a
This will generate mylibname.a, which you add into your .pro file:
win32:LIBS += mylibname.a
You have to provide paths to all the files, or copy them to the right folders, of course.
You must also modify the header file to your third party program so that all the symbols in the DLL that you need to link to are marked for import with Q_DECL_IMPORT. I do this by
declaring all functions in the .h file as:
extern "C" {
MYLIBAPI(retType) FirstFunctionName(arg list...);
MYLIBAPI(retType) SecondFunctionName(arg list...);
...
MYLIBAPI(retType) LastFunctionName(arg list...);
}
where MYLIBAPI is
#define MYLIBAPI(retType) Q_DECL_IMPORT retType
We use the MYLIBAPI(retType) format as this allows us to adjust the header file for use in both import and when creating DLLs and it also allows us to work with a wide variety of different compilers and systems.
Doing this, I managed to link QT in MinGW to a DLL that I generate using VS 2005. The routines in VS were exported as __stdcall. You should look at the dlltool documentation for adding underlines or other prefixes to the names in the library.
You need to make the function's declaration available to the linker as well as providing the path to the dll in which it's located. Usually this is done by #including a header file that contains the declaration.
You also don't need the Q_DECL_IMPORT macro in the client - this would be used in a Qt library's header to allow client apps to import the function. A class or function would be conditionally exported/imported depending on whether the library or a client is being built. More info can be found on this page.
Is your dependency a third party dll or something that you've created?
How can I remove this link warning? You can see code segment that causes this warning.
static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
//bla bla
// Exported DLL initialization is run in context of running application
extern "C" void WINAPI InitGuiCtrlsDLL()
{
// create a new CDynLinkLibrary for this app
new CDynLinkLibrary(GuiCtrlsDLL);
// nothing more to do
}
warning C4273: 'InitGuiCtrlsDLL' : inconsistent dll linkage
I have also export and import definitions, like:
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
The purpose of the preprocessor statements:
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
is to make sure that the header file declares the class or function as __declspec(dllexport) in the .dll where it is defined, and as __declspec(dllimport) for any other .dll that might want to use it.
For this to work, _GUICTRLS must be defined when compiling the exporting .dll, and not defined for any other .dll. Generally you would expect _GUICTRLS to be defined in the project properties, under C/C++ -> Preprocessor -> Preprocessor Definitions.
The compiler error you are seeing usually happens because either _GUICTRLS is not defined for the project that is doing the export, or it is defined for multiple projects, usually resulting from cutting an pasting from one project to another. You will also see this if _GUICTRLS is defined in a header file that is included in multiple projects.
There are multiple possibilities:
1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
You use AFX_EXTENSION_MODULE. This means that you are implementing an MFC extension DLL. For such extension dlls you have to define the preprocessor _AFXEXT. Set this in the C++ compiler settings of your Visual C++ project
see:
How To Use _declspec(dllexport) in an MFC Extension DLL: http://support.microsoft.com/kb/128199
AFX_EXTENSION_MODULE Structure: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx
TN033: DLL Version of MFC: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
2) It is likely that you have a duplicated definiton/declaration.
In addition to reading the warning message, pay attention to where it occurs if you have multiple projects as part of a workspace.
I wasted time looking for a problem in my DLL which was compiling and linking correctly. The workspace was also building the main application and my error was that I had inadvertently included a new (DLL) source file into the build file list of the application itself.
The main program requires the DLL header mynewdll.h to import things but does not require the source file mynewdll.cpp. (The code is brought in at run time with a DLL.) I have a habit of including header and code files into projects as a pair, and this is where I had gone wrong.
I would have detected the error much sooner if I had been alert and noticed that the DLL project linked with no errors and it was the main program that complained!
My DLL source code and project was error free and it was only the way I tried to build my executable that was faulty.
That warning is usually caused by a duplicate definition of a function with different use of dllimport. Are you sure you didn't do this?
[ CMake inconsistent dll linkage ]
I encountered the following issue + solution with the __declspec(dllexport) + __declspec(dllimport) :
# # #CMakeLists.txt
add_defintions(-DMYLIB=1)
# The above was the solution...
# (MYLIB is used in the standard ifdef + define MYLIB_EXPORT syntax)
# Below: seems to get overruled by other directory's headers:
set_source_files_properties( file1.h file2.h COMPILE_FLAGS "-DMYLIB=1")
This was annoying because a number of sources say to use the 'set source file properties' command to get better granularity but the doc is not clear on what happens to file1.h's declares when included from a different directory... better stick with add_definitions( -DMYLIB=1 ) for now!
To catch this problem: in your Foo.cpp file:
#include "export.h"
#if defined(MYLIB)
#if defined(OTHERLIB)
static_assert(0,"error, check your definitions!");
// OTHER depends on MY; can't have both of these flags being set!
#endif
#endif
struct OTHER_EXPORT foo
{
};
See that you are not defining the exported symbols in a different project. Also clean all the intermediate files by hand and recompile.
To elaborate the answer of damian with an example. I read it but didn't understand at first glance.
You have a shared library with a source file compiled in that contains the function. In a new project you use the library and in addition you compile also the source file to use the function (I forgot that it is already in the library). Within the library the functions label is exported, within the additional compiled source file the functions label is marked to be imported. That's the conflict.
In my case, error C4273 was caused by trying linking to .lib file from a DLL dynamic load tester app in Qt5 by msvc2017_64 toolchain. Removing the reference to .lib file by changing LIBS setting in .pro file have the problem solved.