I have a library and I want to get all mangled function and variable names. I will put those names in a .def file to import them in another project.
I'm programming in c++ using Vs2019, how can I get the function names for my .def file?
I've thousand of functions and variables and I need a process to get them automatically
ADD.
The dumpbin /archivemembers seems not work, it's possible retrieve the list of mangled names after the build of the library? Where are those names?
Answered here: How to See the Contents of Windows library (*.lib)
You can run either of these commands at the Developer command prompt:
dumpbin /archivemembers foo.lib
or
lib /list foo.lib
which will give you a full list of symbols in your library.
However maintaining this def file is quite tedious, and exporting all symbols is probably inadvisable. I suggest you look at the alternative method of using __declspec(dllexport) to selectively export symbols from a DLL. You can define a macro which exports while building the DLL itself, and imports when building client code. By tagging the classes and functions in this way, each time you build, the exports will be regenerated and there is no separate .def file to maintain.
Related
I have a .dll I want to statically link to my C++ exe. I have created a header I believe to contain accurate function signatures, so I need to build a lib file from my dll. I use dumpbin to get the names of the functions in the dll, but most functions are nameless and have only ordinals. What should I put in my .def file then?
I have managed to find few batch scripts that create lib file from dll but they just ommit those nameless functions.
An in depth tutorial on lib, def, obj files and linking that goes to the bottom of the matter and is easy to follow would be greatly appreciated from many people I think, although I will be happy to just solve my problem aswell.
I am using Visual C++ Express 2010.
If the functions are only exported by ordinal (that is each export is decorated with NONAME) then the name doesn't matter you can assign whatever name you like. Of course you better know what each ordinal is supposed to be.
I don't understand this paragraph :
Exporting functions in a .def file gives you control over the export ordinals. When you add an exported function to your DLL, you can assign it a higher ordinal value than any other exported function. When you do this, applications that use implicit linking do not have to relink with the import library that contains the new function. This is very convenient if you are designing a DLL for use by many applications because you can add new functionality and also ensure that it continues to work correctly with the applications that already rely on it. For example, the MFC DLLs are built by using .def files.
Why application doesn't have to relink with the import library in case of the usage of a .def file instead of __declspec(dllexport) in the case of a function adding into the dll ?
cf https://learn.microsoft.com/en-us/cpp/build/determining-which-exporting-method-to-use
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.
Ok, if you have a .def file you can use it to create an import library.
I.e. mydll.lib for MS VC++ or mylib-dll.a for GCC
Compilers and linkers prefer their own binary format import libraries, usually not compatible with each-other. This is especially does mater when you'r DLL is written on C/C++ but your program is written on something else like Ada/FORTRAN/Object Pascal etc or vise versa. So .def files can be used to create a compatible import library.
Paragraph telling you a way to hide some functions from import library, with manual editing .DEF file and instruct linker to hide some functions.
Below is an excerpt from link1.
Microsoft introduced __export in the 16-bit compiler version of Visual
C++ to allow the compiler to generate the export names automatically
and place them in a .lib file. This .lib file can then be used just
like a static .lib to link with a DLL. In newer compiler versions, you
can export data, functions, classes, or class member functions from a
DLL using the __declspec(dllexport) keyword. __declspec(dllexport)
adds the export directive to the object file so you do not need to use
a .def file.
I understand the above paragraph to an extent but not very well.
Below is an excerpt from link2.
When building the DLL, the linker uses the .def file to create an
export (.exp) file and an import library (.lib) file. The linker then
uses the export file to build the DLL file. Executables that
implicitly link to the DLL link to the import library when they are
built.
Now, this makes me confused and made me ask the below questions:
Could anybody, in simple words, tell me what the term exporting
really means? I believe this is making an object accessible from one
piece of the code to other - but hey !!
When building projects with old libraries, I see .def file in majority
of them. But the latest compilers automatically exports objects. Would
the presence of the .def file cause any conflict when converting a older
version visual studio project to the newer one?
What is the use of the .lib(the so called import file) after the generation
of the .dll. Can it be safely deleted?
ARRGGGH !! What is the difference between a static library(.lib) and import library(.lib)? Blunder, huh? But still !!
Is the windows specific phenomenon? I believe it is not. What is the Linux counterpart of the so called import file?
Please feel free to rephrase the question if it is not already lucid.
tell me what the term exporting really means?
It simply means telling the linker that it needs to put an entry into the DLL's export table. The operating system loader uses it later to glue code in different modules together at runtime.
I see .def file in majority of them
Could be very old projects. Or it was just never started as a project that was meant to create a separate module. Like a static library so the source code doesn't have the __declspec attributes. Cross-platform libraries are pretty likely to fit that bill. The C and C++ language specifications still don't have a way to create modules in a standardized way. Everybody does it, nobody does it the same way. Massive time drain.
What is the use of the .lib(the so called import file)
It is necessary in the project that uses the DLL. The linker needs to know that the identifier lives in another building and can't be resolved at link time. It puts an entry in another table that the operating system loader uses, the import table. It is a very simple file, it just list the names of the exported identifiers. Theoretically the DLL itself could be used by the linker to figure this out. Practically that doesn't work because the exported name doesn't have to match the actual name.
What is the difference between a static library(.lib) and import library(.lib)
A static library contains code that is linked into the project that uses the library. An import library does not contain code, just a hint that the code is available elsewhere.
Is the windows specific phenomenon?
Roughly, yes. The Unixes have the same concept but implement it very differently.
I inherited a huge C++ multi-project solution with many dynamic libraries but without any
__declspec(dllexport)
I learned that one does not necessarily have to insert any dllexport (would be much work) but that one can use a .def file in addition to corresponding .dll instead.
In order to try that I built a "DLL Hello World" project from here, removed the dllexport from the header and...failed desperately. In the words of already cited page, my key question is how to
"[..] use the .def file when building the DLL."
My .def file is (I try the code only with the Add method):
LIBRARY MathFuncsDll
EXPORTS
?Add#MyMathFuncs#MathFuncs##SANNN#Z
How do I use it when building the DLL in Visual Studio 2010 in order to export the Add method?
After having passed half a day in front of this problem, I just found the solution: it is described here.
To resume the process of symbol export with .def files in VS2010 using my own words:
Tell VS2010 to compile a dynamic library (.dll). This is done in the Property Page of the library's project.
Craft a module definition file (.def) by using mangled (decorated) names (at least when Your language is C++). If You make use of dllexport You can display already exported symbols of Your .dll as described here. If You haven't anything exported yet, see this post.
Add the .def to the library definition in its Property Page.
Compile
Verify the correctness of Your work, for example with Dependency Walker by opening the dependent file, e.g. .exe. You should see the just compiled library in a dependency tree below the dependent file. There should be no errors or warnings, e.g. no red colour.
If You have further questions concerning .def files, look out for the terminus "Module definition file".
Is there, a perhaps undocumented way to prevent linker from creating IMPLIB for a DLL or an EXE, despite having __declspec(dllexport) directives within the source code?
Specifying no /IMPLIB results in .LIB created with a default name.
This is important when the declspec directives arrive from 3rd party code which is not under control. This is, for example, the case with boost::serialization. A possible solution would be a way to "undeclare" a DLL export. DEF file also cannot do it (AFAIK), because it can only add to the export list but not remove from it.
Many 3rd party code does not use __declspec(dllexport) directly, but hides it under a macro in order to control it. Typically they want to switch between dllexport and dllimport depending on where the header file is included (inside the dll implementation or by the user of the dll)
If that is the case in the library you try to include it should not be too difficult to alter this behavior via macro manipulation to meet your exact needs.
For example, boost::serialization check the config.hpp and see how you can control it.
According to this, if you supply the .exp file when linking, the linker will not create a .lib file. To be honest, though, I can't tell if this helps in your case.
There is not any way to do this with a linker option, using /implib:"nul" fails miserably when the linker uses it to name the .exp file. The most practical solution is to remove the files again after a build. Project + Properties, Build Events, Post-Build event and paste:
del $(TargetDir)$(TargetName).lib
del $(TargetDir)$(TargetName).exp
Using a .def file containing your exported functions marked with the PRIVATE keyword will tell the linker to skip placing the symbol in your import library.
Refer to this MSDN page for more information about MSVC's .def file syntax.
Nowadays, you can use /NOIMPLIB and /NOEXP in the advanced linker options as per this bug ticket. Works for me on Visual Studio 2019.