Why do I need a.a /.lib file to connect a dll?
To build a program that is statically linked to .however, the following command was sufficient:
$(CC) bin\main.o -L.\bin -lcompare -o program.exe
At the time of the build, the bin folder should contain compare.dll. But if I do the same thing from CodeBlocks, then in order to statically link the dll, I need to add the file compare.a to the linker parameters, which is obtained when building the. dll. Why the development environment is not simple enough .what if the naked compiler swallows it?
In addition, I I came across this example of a dll build command:
gcc -shared -o tst.dll -Wl,--out-implib,libtstdll.a dllfct.o
I understand that this command, in addition to the dll, generates a file libtstdll.a. Why is this done via -Wl? We just link the files, dllfct.o is already assembled, right? Do I understand correctly that the file libtstdll.a can then be simply linked to the program without any -lmyldll?
1 answers
You are confusing something, the DLL can not be linked statically at all. The first command tells the compiler to look for the libcompare.a file or libcompare.dll and link either statically or dynamically (depending on what is found).
A file with the extension a or lib, which is generated with the parameter-Wl,--out-implib - this is an import library, contains information about the exported DLL functions. GCC, unlike MSVC, supports direct linking to a DLL without the need to enclose the library. import, so you probably don't need it.
If you are interested in why the concept of "import library" was invented at all, then the reason, I think, is speed. It is much faster to process a small file with a list of functions than to parse the entire DLL and extract it from there.