We know that when linking a static library, the linker copies the relevant code from .a file to the executable binary file. And when linking a dynamic library, the linker just copies the addresses of functions it found in .lib file (under Windows) into the binary file, and the functions themselves are not copied. At runtime, the OS loads the dll, and the program runs the code according to the addresses. The question is, could I use the .lib file and dll to link the dynamic library statically? The linker reads addresses from the .lib, and then copies relevant code from the dll to binary file. It should work, right?
Asked
Active
Viewed 193 times
2
-
Just a reminder, check if the library is LGPL. And sort out all the legal issues before actually doing it. – user3528438 Oct 16 '15 at 13:08
-
Maybe if you write your own toolchain to do this, or maybe there's even something on the internet that tries this, but certainly not with any of the standard tools. – MicroVirus Oct 16 '15 at 13:08
-
@MicroVirus So you think that this idea is possible? – yvbbrjdr Oct 16 '15 at 22:13
-
@yvbbrjdr Only theoretically, but I've never investigated the matter, so my thoughts on it don't have much weight. – MicroVirus Oct 17 '15 at 11:25
-
@MicroVirus OK. Then I am going to write my own toolchain just for experiment. – yvbbrjdr Oct 18 '15 at 11:30
2 Answers
2
I have no clue whether your idea could work, but do note that -- on Windows, with Visual Studio at least -- a static library is something very different from a DLL.
With VS, a static library is basically just an object file container, that is, you have a .lib file, but that .lib file is just a container for all the .obj files that the compiler produced for the project.
The important thing here is that the .objcode in the static library hasn't gone through the linking stage yet, no linker has been involved.
Whereas the DLL is (finally) produced by the linker (from object files).
So the question here is really one of toolchain support, since the DLL is already a linker output, I doubt you could get the linker to re-link its PE code directly into the executable.
Martin Ba
- 37,187
- 33
- 183
- 337
-
-
@yvbbrjdr re-link doesnt mean anything specifically. Just that the linker would have to link again what it already linked once. – Martin Ba Oct 18 '15 at 06:31
1
If you want to link the .dll at build time instead of run time yes, it can be done using the .lib file that corresponds to the .dll. The exact method depends on what you are using to build your application.
In Visual Studio you start by adding the .lib file in Linker->Input on the project properties.
While this is static linking it does not copy the .dll code into your executable; you still need the .dll to run the application.
Additionally, if the .dll is something you developed and/or have the source code, it can be modified/rebuild as a static library and linked into your executable (so you will not have a separate .dll file).
SunKnight0
- 3,331
- 1
- 10
- 8
-
You might have misunderstood me. What I mean is to abandon dll and copy its code into the exe. – yvbbrjdr Oct 16 '15 at 22:09
-
1I do not believe that is possible with a 3rd party dll. Only by recompiling it as a static library if you have the source code. – SunKnight0 Oct 16 '15 at 22:41
-
A combination of technical and IP reasons. The very point of a dll is the ability to improve/update it without having to recall/recompile/update all the programs that use it. Embedding it into the program defeats that purpose. It would also allow and IP protected dll to be potentially illegally distributed invisibly inside an application. – SunKnight0 Oct 19 '15 at 17:48
-
1So what I am talking about is not whether this way is against the purpose or the law. I am just wondering could this way work. – yvbbrjdr Oct 20 '15 at 10:21