.Def Files C/C++ Dlls

.def files C/C++ DLLs

My understanding is that .def files provide an alternative to the __declspec(dllexport) syntax, with the additional benefit of being able to explicitly specify the ordinals of the exported functions. This can be useful if you export some functions only by ordinal, which doesn't reveal as much information about the function itself (eg: many of the OS internal DLL's export functions only by ordinal).

See the reference page.

Note that the names in the .def file must match the names in the binary. So if you using C or C++ with 'extern "C" { ... }', the names will not be mangled; otherwise you must use the correct mangled names for the specific version of the compiler used to generate the DLL. The __declspec() function does this all automatically.

What is the *.def file at c++ project?

The .def file is normally not used for building an exe. Extract from LINK documentation :
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 ... If you are building an .exe file that has no exports, using a .def file will make your output file larger and slower loading.

Unless you are building a DLL, banana.def should not be used.

Pros and Cons of Using .def Files

That is because of some specifics of MSFT implementation of shared objects (or DLLs). In Microsoft world, in order to import function into your process, you need not only the shared code itself (.dll), but you also need the special 'import' library - the .lib file. This file is statically linked into your application (as it is a static library). This library provides 'glue' between function names and function ordinals.

Normally, every time you release a new version of DLL, all applications which use it will have to be relinked with the new, accompanying version of static import library (.lib) to be able to use this new DLL library. This is due to the fact that function ordinals are generally no longer valid after you have created the new library. However, if you are using .def file, you can assign ordinals manually, and ensure the ordinals remain the same for previously available functions - and thus .lib file will still be valid.

Importing DLL using a module definition file (.def)

You can just give your clients the .h file(s), the .lib import library, and the .dll file itself. They don't need the .def file.

If I recall, the declspec import thing allows for a minor optimization by the linker. Something about the import table. I'll look that up later and update the answer if I can find it.

C++ How to specify namespace in def file

Def files must contain decorated names. (i.e. function names as the compiler and linker sees them)

You can read up the details on Microsoft's site, but here's the relevant section:

If you are exporting functions in a C++ file, you have to either place the decorated names in the .def file or define your exported functions with standard C linkage by using extern "C". If you need to place the decorated names in the .def file, you can obtain them by using the DUMPBIN tool or by using the linker /MAP option

Personally, I prefer using /MAP. I find it a lot more straightforward than using the swiss army knife that DUMPBIN is.

For reference here is a link to the documentation of decorated names in general.

How to generate DLL from existing C++ code using DEF file in Visual Studio 2010

After repeatedly coming across this problem for a couple of years I've today found a solution. It's a little hacky, but it actually might be the best possible way with Visual Studio.

Since you don't want to export EVERY possible symbol (especially since your DLL may include large static libraries itself), and you can't edit the files with symbols you want to have available (for me it's because they're 3rd party libraries which must be statically linked to follow their usage pattern), and DEF is the best solution.

If we have:

• Application (EXE)
• Library (DLL)
• Library has .DEF file which means that when you build, symbols listed in the .DEF will be exported to the Library .DLL and listed in the .LIB file.
• .DEF file is empty
• Application links Library's LIB file

NOW BUILD!

OK, we get a lot of linker errors...

Now go to the "Output" tab, and notice that within the text of the output is the symbol names at the end of each linker error line:

We can create a little script with takes the last 'word' of every line, takes off the brackets, and then put that in your DEF file. And it works!

Like I said it's a little hacky (since you only end up with the symbols used by the Application at that time). But actually since you don't want to export everything, and you might need symbols in the libraries which that library statically links, it's probably the most accurate way of going about this.

(NB : In my case it's mostly a problem with trying to get the plugin DLL have access to symbols in the application EXE)

Specifying the DEF file when compiling a DLL with Clang

Finally figured it out -

1. We can use the -Wl flag in clang to pass some comma-separated arguments to the linker.
2. DEF files can be specified using /DEF argument

Example

clang -shared structs.c -o structs.dll -Wl"/DEF:structs.def"

Export function from a DLL - Use DEF file or dllexport?

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

---

Related Topics