Everybody, I am a beginner and I have still have some things I am confusing about.
I have a program qt which I want to include a extern library. Generaly, to include a extern library I use the macros :
INCLUDEPATH += "path/to/the/include/headers/file"
LIBS += -L"path/to/where/the/lib/are" \
-llibname // .a for gcc .lib for mscv
Then I can use the library in my program. But at the end the qt aplication program use the .dll associated to the lib name. So my question, why can't we use directly the .dll in Qt ? I don't know very much the difference between a ".lib" and ".dll" execpt a ".dll" is used at the runtime.
My problemen is have a library with only the dll and the include headers file. Is there a way to use this library like this or I must have the .a or .lib associated ?
EDIT :
Ok now,thanks to the useful advice, I understand better the difference between, .lib and .dll and how to use a dll without a .lib with only header. But I am having a issue. With the header, I can create the object, the compilator doesn't bother about it can't find the object and its method, but When I compile, I have some problems about "undefined reference to a method".
If I correctly understand, the reference cannot be found because the reference are defined in the .lib, that's why it can't find it. So my question :
How can I say to the compilator that the reference to a method will be defined at runtime and not at compile time ?
EDIT2 :
Ok so apparently you can get a pointer of an object with a dll but you can't use its methods, so I think I am facing the wrong way. Thanks again for you answer.
Best regards,
There are 2 types of lib file, see this asnwer: https://stackoverflow.com/a/2375144/2064646
You can just use a .dll without .lib file, but through GetProcAddress function.
Related
We have an excellent MFC/C++ project that handles the data to and from a legacy database. All classes are exported with AFX_EXT_CLASS (which is dllexport if i am not misunderstanding it). I am currently writing a wrapper so that we can use it in C# applications. This is my first real wrapper, so please bear with me.
This is what i have done:
Compiled the project with /Yc /Gm- /Clr. It produces a .lib and a .dll.
I have access to the source so, i added the path of the header files in my C++/Cli project. It therefore recognises the types.
I added the .lib to the linker input in the C++/Cli project.
I have added the .dll as a reference in the C++/Cli project.
In the C++/Cli project, i have a stdafx.h that looks like the stdafx.h in the native project.
If i understand this correctly, the .lib is the implementation, the .dll is the "wrapper" to be able to reference it as a .net-dll, and the header files are the class definition.
Now, i can define native objects in the C++/Cli project, but when i access functions therein and try to build it, it throws external reference not found errors on the objects that i am trying to define.
This is understandable because it can not know that the header files point to the implementation in the .lib. The header files are used as is.
What am i doing wrong? Am i supposed to point at the header files? Should it not use the .dll to find the class definitions that are implemented in the .lib file? Should i create a .def file to point at the library?
There seem to be a missing piece to this puzzle and i am expecting to experience an aha-moment any moment now...
Please note that this is not a general linkage question, it is specifically about the practical use of AFX_EXT_CLASS exported classes, MFC and C++/CLI.
Cheers and thank you
You don't need your step 4. Also, try to don't use Precompiled headers like stdafx.h in your project, Go to C/C++ -> Precompiled Headers -> Not using precompiled headers and Check Linker -> Additional Dependecies -> Inherit from parent or project defaults. Finally, check the error message link if it's point to windows library use missing try to include .lib library using #pragma comment (lib, "yourlib.lib")
I have a c++ application which is using a DLL. Now, I want to access a method from that DLL in my application. But, compiler is giving me "unresolved external symbol" error as it is unable to find the method even though my function in DLL is exported properly. When I include .lib file path of respective DLL in my application's additional dependencies, the error got resolved and application is working properly.
But, some people told me that I should not include .lib file when I am using a DLL. It is just like statically linking the DLL.
1) Is inclusion of .lib file when using DLLs in application, is good practice or not ?
To avoid this .lib file inclusion and to avoid calling GetProcAddess for every exportable method, they suggested me to write some wrapper class and create a virtual method to access the method from the class in DLL. I didn't understand this approach.
2) Can anybody explain why I need the wrapper class and how this abstract class can provide me the function I required ?
Thanks in advance.
1) Is inclusion of .lib file when using DLLs in application, is good practice or not?
According to msdn you are required to link to .lib files when using dll. Consideration of good or bad practice comes in when you have choices. Which you don't have here.
they suggested me to write some wrapper class and create a virtual
method to access the method from the class in DLL.
Well if you create a wrapper class then you will have to link that wrapper class with the dll and that will bring you in the same place again.
Inclusion of .lib file when using dll is used by all the shared libraries I've used on Windows.
It's important to understand that, on Windows platform, not all the libraries with .lib extension are static. Here is a discussion that explains how to understand if your .lib library is a static library or an import library.
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."
This is interview question.
Is it possible to link lib dynamically like a DLL ?
For example, for DLL, we use LoadLibrary and call exported functions.
Is it possible to use lib file in same manner?
No. .lib library are statically linked, and that is the purpose they're created for, to resolve the name symbols at link-time by Linker, and link-time occurs before runtime. They're often referred to as "static libraries" (that is why I added this tag in your question!). That is the brief story of lib.
However, you can create a DLL wrapper, if you really want to link at runtime.
No. Create a DLL instead or, if you do not have the source, wrap the functionality in the .lib with own DLL interface.
No. It's not possible. A DLL is module with a PE32 header with all information to load it into a process. A LIB is only a archive of OBJ files.
And despite others say it's easy to wrap a DLL around it, this can be quite difficult. The reason is, that a .LIB not only resolves some dependencies but can also have unresolved externals.
As long as these unresolved externals require only the compiler's runtime library wrapping in a DLL might work. You can check this when you create a DLL project, probably with a minimal C++ source, and try to compile. Than you see, if further externals must be resolved with other libraries.
One important problem may arise with memory management. When yo link statically with a .LIB you will use all the same definitions. If your library comes with own implementation, let's say of malloc-stlye functions, this will not be linked to your application as long as you add all these symbols to the EXPORT list. Finding the list of public symbols that should be included in the EXPORT table may be a pain.
Yes - not directly, but with a very small amount of work.
Create a new .DLL project, link the .lib, define which functions you want to export in a .DEF file then compile.
It's pointed out by this answer:
Failed to link mysql5.1.39\bin\libmySQL.dll
But I don't understand why,.dll is essentially the same as .lib except for there is only one copy of it used by different processes.
Does it have anything to do with the IDE?I'm using visual c++ 2008 express
UPDATE
Anyone know a free tool to convert .dll into .lib in windows?
You are wrong on two counts. Firstly, DLLs and LIBs (static libraries) are very different beasts. The LIB you are talking about (I think) is the export library, which is simply a list of names in the DLL. This library is typically produced when the DLL is compiled and is shipped with the DLL if the DLL is intended to be linked to by other developers.
To use a DLL with a modern IDE (I don't use VS) you typically include the matching .LIB (export library) in the project. At run-time you must make sure the DLL is available to your program - the simplest way to do this is to put the DLL in the same directory as the executable.
And secondly, DLLs can be used with C++.
DLL are specific windows executables which load on runtime. Their equivalent in Linux is the *.so .
If you want to understand what's the difference between a DLL and a static lib see here.
Main reason has probably something to do with dll-file being an output of the linker (link.exe). This command line utility doesnt know how to read dlls, only how to write them.
Actually sometimes .lib-files contain more than a list of functions. For example libpng.lib works as a standalone file, without any dll file.
In order to use a DLL in C/C++ you need to link with what is called an import lib. This is a small .lib that contains the names/ordinals the DLL exports in a format that the linker understands. Once this has been linked in, the resulting binary will be able to use the DLL. If you do not have the appropriate import lib, your C/C++ compiler should come with a tool to generate one from the DLL.
You can use the following analogy to understand the difference between a dll and a lib file.
the dll is like the source .cpp file while the lib is the header .h file.
While this is not exactly true, the DLL holds the executable code while the LIB file tells the linker how to glue the code together.
It is also possible (in some cases) to generate the lib from the dll. Basically, all you need to know to call a function is the function entry point in the dll, the number of parameters and the size of each parameters. Sending relevant information is then your own problem.