Is it possilble to link .so file into .a file
A 3rd party only offer a so
Our .a lib depend on it.
And we don't want to give customer too much dependency
No, you can't convert a shared lib back to a static lib. There is information in the .o files that gets discarded when they are welded together into a .so file. If you really want static linking, you'll have to persuade the third party to also ship you an archive.
I am creating a static library. I have gone through the win32 application, static library, no precompiled headers. The file is a .cpp I am assuming that I can export this to the actual .lib file, or is it suppose to be .lib from the start?
Also, I keep getting the cannot open source file stdafx.h, which I have included within my main static library .cpp file. Tell me, am I suppose to do this?
Thanks
I have a Static library project that depends on an external library. I've added the folder of the external library to the 'Additional Library Directories' setting of the Static library project. When I then create a project and add a reference to this Static library project it still fails to find the external lib file at link time. Only when I add the folder of the external lib to the 'Additional Library Directories' setting of the application project instead it finds the lib file.
Is there a way of adding something to /LIBPATH automatically so that each application project that references the Static library project automatically finds the external lib file? I don't really want to specify the folder in the general 'Library Directories' folder. I also can't use a '#pragma comment(linker, "/LIBPATH...")' instruction.
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.
I have learned that you can:
Convert a .DLL file into a .DEF file, which includes its exports
(Edit: This doesn't work with many conventions)
Convert a .DEF file into a .LIB file, which you can use to link to the DLL
Why can't (most) linkers link to a DLL given only a .DEF file, instead of a .LIB file?
Ultimately, the answer here is 'because noone wanted it badly enough and it doesn't really help anything'.
The DEF file is an input file that creates an import lib for the DLL. And then, later, when the DLL is being consumed by another link, the importlib is itself an input. The importlib looks like something special on the outside, but when you look at the inside it's really just a slightly special lib with objects in it.
It totally would be possible to modify the linker to take a def file (or a DLL, for that matter) directly.
But the design centre of the linker is that it takes objects as inputs and outputs a PE executable. So taking a DEF or DLL as an input goes outside the design pattern.
Beyond that it'd be rather pointless - allowing the linker to take a DEF file or DLL as input would neither enable any important new scenarios, nor does leaving this feature out block anything. Converting a DEF file you have (even without the actual DLL) into a usable importlib is the work of a few moments (simply create fake empty function for each DEF entry and link that). So there's no reason to add the ability to link a DEF file directly.
Martyn
In terms of MSVC, .lib files are always static libraries. They get linked in as a compilation unit along with all your compiled .c/.cpp files, so all of the library's code is included in your final executable.
Some .lib files, however, (in particular most of the Windows system ones) merely contain stubs which tell the OS to load the desired DLL at loadtime and then the stubs route function calls to the DLL. But, those stubs are statically linked into your executable. Your program will then use DLLs (and gain all the advantages and disadvantages thereof), but since the named DLL functions it requires are happily located in the .lib (and thus actually located in the executable itself), your code doesn't have to know it's using a DLL (specifically using declspec(dllimport)).
A .def file is merely used as a sort of "settings" or "configuration" file during the creation of a .dll to specify what functions the file should export. It cannot be linked to, as it doesn't really describe anything that the linker understands.
You do not convert a dll to a DEF file. The DEF just indicates which dll functions will be accessible from the outside, exported.
From the docs:
A DLL file has a layout very similar to an .exe file, with one
important difference — a DLL file contains an exports table. The
exports table contains the name of every function that the DLL exports
to other executables. These functions are the entry points into the
DLL; only the functions in the exports table can be accessed by other
executables. Any other functions in the DLL are private to the DLL.
The exports table of a DLL can be viewed by using the DUMPBIN tool
with the /EXPORTS option.
You can export functions from a DLL using two methods:
Create a module definition (.def) file and use the .def file when
building the DLL. Use this approach if you want to export functions
from your DLL by ordinal rather than by name.
Use the keyword __declspec(dllexport) in the function's definition.
When exporting functions with either method, make sure to use the
__stdcall calling convention.
Use the provided link to learn more about exporting from your dll's.
I think you got down voted because your point is not really clear, at least not to me. Also check this. It explains how to choose the export method.
Mehrdad, this isn't always a question of how to LINK to a DLL, as I, personally have NEVER linked a DLL using a .DEF file. What I HAVE done is take someone else's DLL, and very painstakingly constructed a header file, or rather, function prototypes that I could use with
LoadLibrary() in C, Declare Function ... Lib "Foo.dll" Alias "OrdinalName" in VB, and
[DllImport()] in C#.
Of course, this is RARELY done, as if you are using a DLL for something, normally you have permission to do so, and the authors provide the .lib's, and the headers to go with the binary DLL file.
I've never done the exact techniques you speak of, by converting a .DEF info a .LIB, etc... But, I suppose it would be easy to take a lib, or the DLL itself and export .DEF from it. Now, THAT I actually HAVE done, in a project where the DLL code was built with a vbScript that took code from the main project, and created an API out of all the existing, compiled, and tested code. This level of complication was only done because I had no idea what functions were going to BE in the DLL, as the main project could change at any time, so a static .DEF file would have never worked. So, I had to build the DLL once, capture the dimpbin /exports, undecorate the functions, and then build the .DEF file, and re-link the DLL.
If you find yourself in that type of situation, perhaps you need to re-think your original designs, and fix the problem from there...
As for .LIB files, USUALLY you'd only NEED those for static linkage, but they are also used when the .H file is available, often making debugging a just a little nicer...