I have downloaded some dll files and with it came also pdb, exp and ilk files. Now I need to know do I need to put them in my system file, or not and what is the purpose of each of them in the general?
PDB files contain debug information and are useful if you need to step through the DLL's code at any point.
ILK files are used by the linker. They are not needed unless the DLL is to be recompiled.
EXP files contain information about things exported from the DLL
.ilk files are intermediary files created by the linker during the development cycle. .ilk files serve the purpose of incremental linking. If the linker does not find and .ilk file when trying to do incremental linking, then it will do a full linking and reproduce the .ilk file. Incremental linking is meant to speed up the linking process. You can safely delete .ilk files.
.exp files are for developers too. .exp files are created for .exe and .dll files that export some symbols. Their purpose is similar to .lib import libraries, but there is a subtle difference. .exp files are always created, even if the creation of the corresponding .exe or .dll fails at link time. By contrast, .lib import libraries are created only when the corresponding .exe or .dll linkage succeeds. .exp files help linking interdependent components. For example, an .exe might provide access to its common resources for its plugins by exporting some functions. The plugins also provide exports for the .exe to call. Interdependencies like this cannot be successfully linked. The .exe linkage will fail, because the import .lib for the .dll is missing. Consequently no .lib for the .exe will be created. The linkage of the .dll will fail because the import library for the .exe is missing. Export files however will be created even if linkage failed, so the .dll could link against the .exp file rather than the .lib file for successful linkage.
Related
I know, roughly, that when statically linking to a .lib from an .exe the code is placed in the .exe (missing some detail of course).
But when getting a stack trace from something like WinDbg, do i need to have a pdb for both the exe AND the lib, or will the pdb for the exe contain the information from the pdb for the lib (in the same way the exe contains the lib)?
I'm asking because in Debug building with MSVC (using CMake) I get pdbs for my .libs, .ddls, .exes but in release I can only get ones for the .dlls and .exes
Check this answer. There are compile options.
If you use /ZI or /Zi (C/C++ -> General -> Debug Information Format), then the vc$(PlatformToolsetVersion).pdb is created, which contains the debug info for all of the .obj files created. If alternately you use /Z7, the debug info will be embedded into the .obj file, and then embedded into the .lib. This is probably the easiest way to distribute the debug info for a static library.
My company builds releases with debug info enabled,
But embedding the debug info (with /Z7) was not an option for us,
because we don't want to make Reverse-engineering simple.
Hence, we tested manually, like:
We created a very small App.
Then, built it once as is, to generate App's *.pdb file.
And built it another time, but with linking to a huge static library, to generate App's *.pdb again.
Where said static library had it's own *.pdb file.
At last, we compared the size of *.pdb files.
Conclusion:
The size of the said App's *.pdb file became huge,
meaning, the static library's *.pdb file was embedded.
Either that, or MSVC has huge bugs ;-)
One could go even further, and add an intentional crash to said static-library, to see if *.dmp file's stack-trace can really be converted to file-path and line-number, but above was enough evidence for us.
In environment where we produce multiple builds in x intervals and store the resulting symbol files in server, is there a way to associate the correct path of the symbols for that particular build?
You can use the symbol server. The association between a DLL/EXE and the PDB is done by the linker who adds a GUID in the DLL/EXE and PDB to match both files and now Debuggers or Profilers like WPR/WPA use this GUID to find the correct PDBs:
When the linker generates .dll, executable, and PDB files, it stores
identical GUIDs in each file. The GUID is used by tools to determine
if a given PDB file matches a DLL or an executable file. If you alter
a DLL or an executable file—by using a resource editor or copy
protection encoding, or by altering its version information—the GUID
is updated and the debugger cannot load the PDB file. For this reason,
it's very important to avoid manipulating the DLL or executable file
after it is created by the linker.
Are there any tools or methods for renaming a DLL's dependencies?
I'm working with a large program that uses a significant number of third party dependencies. I'm able to compile nearly all of these dependencies into DLLs with a specific naming convention (i.e. libSomething_x86.dll). However, there is one dependency (FFmpeg) that I can't easily compile, but pre-compiled DLLs are available. So far, I've renamed the DLL files and recreated the import libraries to use the new names. My application compiles, but fails to run because FFmpeg is composed of multiple DLLs and they reference each other (with the original names). Since the new DLL names are longer than the original DLL names, I can't simply hex edit the DLL files. I can't use side-by-side redirection, manifest tricks, or "wrapper"/"dummy" DLLs because the fact the DLLs are pre-compiled and renamed must be completely transparent to the other application developers.
I was hoping to find a method of unlinking the DLL, editing the dependency list, and then relinking the DLL. Is this possible?
Thank you.
To use class library I must have header file and lib file that I suppose contains compiled library code. So, why and when I need dll file? I have breath understanding that in case of dynamic linking I must use dll and in case of static linking there is no need to use dll.
You can have a library project or a DLL project. A DLL is good if it will be used by multiple exes. A lib is good if you want it to become part of an exe.
DLL projects generate both a DLL file and a lib file. The import lib file is very small and just contains a jump table so the exe can be compiled.
When your library is dynamic library i.e, .dll, .lib file have exports table. .h header file have function prototype.
Export table is table of all exported functions from dll.
I am just approaching C++ development (from a C# background), and i am wondering what is the difference between Library Directories in C++ project settings (in Visual Studio):
and the Linker "Inputs" where i can also supply libraries:
Is there any fundamental difference between these?
This setting got fumbled a bit in VS2010, it was much clearer in previous versions. Where the settings you show in your screenshot were present in Tools + Options. Which shows the core intent, they contain directories that are determined by the setup for Visual Studio and its components. The locations of the CRT, MFC, ATL and SDK libraries.
The Linker + Input + Additional Dependencies setting is the important one, there you say exactly what .lib files the linker should link. You can specify the path of a .lib file and be done. But it is not uncommon that you only specify the name of the .lib file, then edit Additional Library Directories to tell the linker where to search for those .lib files. Which is handy if the install location for, say, Boost isn't always the same or you want to switch from one version of Boost to another.
So in summary:
Linker + Input + Additional Dependencies: add the .lib files you need to link
Linker + General + Additional Library Directories: only use if you didn't specify the path of .libs
VC++ directories: don't mess with it
Do note that the last two bullets only specify directories, not .lib files that the linker should link. The first bullet specifies actual .lib files. What is invariably confusing to starting MSVC programmers is that the linker magically knows how to find important .lib files without specifying them explicitly in the Additional Dependencies setting.
That's unfortunately the non-visual part of Visual C++. There are two distinct ways in which a project can specify .lib files that the linker should link without using the setting. The first one is the project template you selected to get the project started. It uses project property sheets, files that specify default settings for a project. You see them with View = Other Windows + Property Manager. An important one is "Core Windows Libraries", it sets the Additional Dependencies setting to link the essential Windows .lib files, the ones you always need like kernel32.lib and user32.lib. Those settings are "inherited" by your project. Otherwise giving meaning to "NoInherit" if you ever run into it.
The second important way is the #pragma comment directive. Which is used in source code, it injects a linker directive. The "lib" variety is important, that tells the linker to link a .lib file. In addition to what you explicitly specify in the linker's Additional Dependencies setting. A very good example of that one is vc/atlmfc/include/afx.h. Search for "#pragma comment". Note the macro soup that selects the proper mfc .lib file, depending on compiler specific settings. And the bunch of extra Windows .lib files an MFC needs to link.
The C++ build model is filled with a maze of twisty little passages. The IDE tries to make you fall in the pit of success but in the process hides what's important to get to the next level of understanding. It isn't different in C#, to know how to make the Reverse() extension method not consume O(n) storage requires digging in.
Most (not all) libraries come with two sets of files:
Header files are #included in the source code that's using the libraries, to provide declarations for functions, classes, constants or whatever else might be needed
Library files are binary code that contains the code of the library. These are used by the linker when it assembles the final executable