I'm just looking for a simple, concise explanation of the difference between these two. MSDN doesn't go into a hell of a lot of detail here.
__declspec( dllexport ) - The class or function so tagged will be exported from the DLL it is built in. If you're building a DLL and you want an API, you'll need to use this or a separate .DEF file that defines the exports (MSDN). This is handy because it keeps the definition in one place, but the .DEF file provides more options.
__declspec( dllimport ) - The class or function so tagged will be imported from a DLL. This is not actually required - you need an import library anyway to make the linker happy. But when properly marked with dllimport, the compiler and linker have enough information to optimize the call; without it, you get normal static linking to a stub function in the import library, which adds unnecessary indirection. ONT1 ONT2
__declspec(dllexport) tells the linker that you want this object to be made available for other DLL's to import. It is used when creating a DLL that others can link to.
__declspec(dllimport) imports the implementation from a DLL so your application can use it.
I'm only a novice C/C++ developer, so perhaps someone's got a better explanation than I.
Two different use cases:
1) You are defining a class implementation within a dll. You want another program to use the class. Here you use dllexport as you are creating a class that you wish the dll to expose.
2) You are using a function provided by a dll. You include a header supplied with the dll. Here the header uses dllimport to bring in the implementation to be used by the current program.
Often the same header file is used in both cases and a macro defined. The build configuration defines the macro to be import or export depending which it needs.
Dllexport is used to mark a function as exported. You implement the function in your DLL and export it so it becomes available to anyone using your DLL.
Dllimport is the opposite: it marks a function as being imported from a DLL. In this case you only declare the function's signature and link your code with the library.
Related
I have a problem with an embedded linux C++ application I've written that consists of an executable and a dynamically linked library. The executable calls a function that is one of the entry points in the library, but that function misbehaves. I've investigated using gdb, and find that the library function, which is supposed to make a call to another function xyz() within the library, actually calls a function of the same name xyz()within the executable.
I'm very surprised this can happen, so maybe I'm doing something stupid. Isn't the library linked within itself without reference to the executable? If the executable wrongly made a call to abc() in the library instead of abc() in the executable that would make slightly more sense, because it is at least linked with the library, although in that case would the linker spot the dual definition? Or prioritise the local function?
I could just rename my functions so none of them have matching names, but I'd like to understand what is going on. I don't have much experience in this area, or with the gcc tools. Firstly, is what I think is happening in the above scenario even possible?
Both the executable and the library make calls to another library.
The link command for the library I'm using is:
powerpc-unknown-linux-gnuspe-g++-4.9.3 aaa.o bbb.o [etc] -shared -o libmylibary.so -L ../otherlibpath -Wl,-rpath-link,../otherlibpath -lotherlibname
That is way how the dynamic linker works. The symbols in executable have higher priority then symbols in dynamic libraries. Dynamic library designer must be aware about it. She must do measures to avoid unwanted symbol mismatch. Most libraries use:
In case of C++ use namespaces. All symbols exported from library should be in a library namespace.
In case of C use a name prefix or suffix for all exported symbol. For example OpenSSL library uses the prefix SSL_ and the public functions have names like SSL_set_mode() so the unwanted symbol collision is avoided.
Do not export symbols from the library that are supposed to be private. If the symbol is not exported from the library then the dynamic linker use the local symbol in the library. #pragma visibility is your friend. See https://gcc.gnu.org/wiki/Visibility
If the library with duplicate symbols is a 3rd party library and its author does not follow the recommendations above then you have to rename your function or perhaps ask the author for a library update.
EDIT
Export/do not export may be controlled by #pragma visibility directive (gcc specific extension):
void exported_function1(int);
void exported_function2(int);
#pragma GCC visibility push(hidden)
void private_function1(int);
void private_function2(int);
#pragma GCC visibility pop
Detail at the link above.
I've searched through some Microsoft tutorials and all related stackoverflow threads to find the right answer. None of them is clear enough for me.
This thread still leaves some doubt.
"__declspec( dllexport ) - The class or function so tagged will be exported from the DLL it is built in"
vs.
"__declspec( dllimport ) - The class or function so tagged will be imported from a DLL"
Well, it hardly makes sense, because what does it mean "import from DLL" and "export from DLL". You can either export from and import to something, or import from and export to something.
My understanding is:
dllexport is used to specify that I want to load this code to the DLL I'm creating, whereas dllimport is used to tell the compiler that I'd like to make use of code from a DLL.
Is that correct?
When you want to use something from a dll, you include the good .h file, which will contain __declspec( dllimport ) ( often done with a #define macro for switching accordingly between export and import when we are compiling).
As a consequence you will import FROM the dll which provides this .h file.
On the contrary when you compile this dll, the .h file contains __declspec( dllexport ), telling the compiler/linker to do the job for exporting such part FROM our dll.
Have you read those:
Exporting from a DLL Using __declspec(dllexport)
Importing into an Application Using __declspec(dllimport)
I am trying to create a dynamic library of the Armadillo linear algebra library, which is originally a header-only library, using VC++ 2010 on Win XP. I created a new project, added the source files, and created a .def file specifying to export only one Armadillo function (the Col class), and I get the LNK2001 error for the Col class. I can create a main and use Col just fine, so I think Col is being included correctly.
I have also tried using "__declspec(dllexport)" on the function definition and it compiles, but the function is not exported since using dumpbin shows nothing, and I can not use the .dll sucessfully. Am I missing something here?
As Armadillo is a C++ template library that uses expression templates, I don't think it's possible to create a DLL out of it.
The expression templates are executed (run) at compile-time by the C++ compiler, whenever compiling code that uses Armadillo classes. Whenever a C++ library uses expression templates (part of template metaprogramming), the library can be thought of as an extension to the C++ compiler.
All the Armadillo code is in headers. As such, even if you managed to export one of the classes (eg. the Col class), none of the associated mathematical machinery (eg. addition, multiplication, etc) would be exported, which is defined all throughout the other parts of the library.
I am playing with DLLs to get a better understanding of them. So I created a simple dll (with load-time dynamic linking) which has functions to Add, Sub and Mul. In the header file for the dll I used __declspec(dllexport) for the function declaration.
For the executable, I added the .lib created after compiling the dll to the properties (for linking). After that I directly called the function Add without using __declspec(dllimport). The program worked. I then changed the function calling to __declspec(dllimport) (Add) and the program worked again.
I am not able to understand what the need of __declspec(dllimport) is? I have not yet coded a run-time linking DLL but from the examples I have seen, dllimport is not needed in that case as well.
Thanks for your assistance.
Module-definition (.def) files provide
the linker with information about
exports, attributes, and other
information about the program to be
linked. A .def file is most useful
when building a DLL. Because there are
linker options that can be used
instead of module-definition
statements, .def files are generally
not necessary. You can also use
__declspec(dllexport) as a way to specify exported functions.
http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx
I was wondering, should we prefer .def way? or dllexport way?
Module-definition (.def) files provide us with more flexibility to define how data going to be exported.
For example, function exported can be anonymous (identified by ordinal) which prevent people without the declaration information from using it.
It can also ddo function forwarding/redirection as stated below :
http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=VS.80).aspx
If you plan on users using your DLL in Visual Basic (not VB.NET), then you may want to opt for using the .DEF file. Visual Basic requires that functions use the stdcall calling convention, and exported stdcall function names are decorated with underscores (_). You can override this function name decoration by explicitly specifying the function name in the .DEF file.
For more information: http://msdn.microsoft.com/en-us/library/dt232c9t%28VS.90%29.aspx