Compatibility of *.dll *.a *.lib *.def between VisualStudio and gcc

Question

this is very confusing. I spent a lot of time reading posts on this on stack, etc. Still confused.

I am using Qt and C++ for coding. In Qt, I am using the gcc optio

Answer 1

Maybe it is worth starting at the beginning and not jump ahead of ourselves and describe the core issue. From this answers to several of the questions can be derived.

The start is the ABI (application binary interface). This defines things like

• how a function is called, e.g. which parameters go into which registers or what location on the stack they put
• how exceptions are thrown
• how objects are layed out, e.g. where the "vtable pointer" goes, what padding is used
• how big the build-in data types are
• how the function names are "mangled" into symbols
• how type information is layed out
• the layout of standard library classes
• etc.

Most platforms define a C ABI but don't define a C++ ABI. As a result compiler define their own ABI (for everything except the C stuff which is typically there). This yields object files which are incompatible between different compilers (sometimes even between versions of the same compiler).

Typically, this manifests itself in strange-looking names somehow being undefined: different ABIs deliberately use different name mangling to prevent accidentally linking an executable which won't work anyway. To work around these your best bet is to build all components using the same compiler.

If you want to determine which compiler a library is build with, you can have a look at its contents using appropriate tools. I realize that you asked for Windows but I only know the UNIX tools (they may be available with MingW):

• nm to look at the symbol names (typically together with less or grep)
• ar to build or inspect libraries
• ident to find special strings embedded in the object
• strings to fond all strings
• c++filt to demangle symbols into their C++ declaration

Looking at the symbols typically yields identifications of what compiler produced them. If you have seen them suffiently often, you can even tell the ABI from the symbols themselves.

There is lots more in this area but I've run out of stamina... :-) In any case, I think this answers several of the questions above.

Answer 2

question 1: you should import .h file and link .a file by linker command and copy .dll near your .exe output.

question 2: you can make .a file by .def file

set PATH=C:\Program Files\CodeBlocks\MinGW\bin;%PATH%

dlltool.exe -d libfftw3-3.def -l libfftw3-3.a

question 3: no. you can make .def file manually and after make .a file.

question 4,5: yes

question 6: I think it is depend on your hardware and operation system not on your compiler.

question 7: I don't know.

question 8: you need only .h .a .dll not .def

question 9: .lib files is for visual studio.

question 10: no you need .def and .dll to make .lib and you can make . def yourself if you don't have it.

set PATH=C:\Program Files\Microsoft Visual Studio 12.0\VC\bin;%PATH%

lib /machine:x86 /def:libfftw3-3.def

or

lib /machine:x64 /def:libfftw3-3.def

Question 11: yes i told you above.

question 12: yes

question 13: no.

Answer 3

A DLL is essentially a compiled application - just in the form of a function library rather than an EXE file. Any other application can use the functions within that DLL by just declaring the function, the dll containing the function, and the parameters and return values and such.

DLLs must already exist on a system if an application is compiled using "dynamically linked libraries", so you must either include the necessary DLLs in your installer, or hope that they already exist on the target computer. Using DLLs makes your app's size smaller overall.

Creating DLLs is just like creating any other application - you just target your build as a DLL rather than an EXE or whatever.

To create any application - DLL, EXE or otherwise - you need the necessary source code and headers. .h files contain declarations for functions and data types and classes and whatnot - they rarely contain code. A .def is a lot like a .h, but usually a set of instructions for a linker.

When you compile, a .h or .c or whatever turns into a .obj - an object file. Multiple object files are linked together to create your DLL or EXE.

A .lib file is a static library - essentially a bunch of .obj files (or one .obj) that have been combined for the linking stage.

The format of .obj and .lib files can be particular to a compiler, and they are rarely compatible between compilers. You must have the original source code, or an .obj or .lib made specifically for your compiler.

When you choose to make an EXE with "dynamically linked libraries", it will be expecting DLLs that it can use. When you choose "statically linked libraries", the linker will locate the .lib files it needs before producing the EXE, and you won't need those DLLs.

Answer 4

I stumbled upon this question when searching for the tool to use to create the .a file using Code::Blocks c++ compiler for windows. Code:Blocks uses MinGW gcc compiler. It was high enough on google to validate my necromancy I think.

Dynamic link libraries (dll's) are a mixed bunch. Some can be compiled in a way that makes them very hard to use outside the programming language and compiler they were created with.

Often however the dll is created with a clean C interface. When that is the case the answers to your questions that I think I can answer is:

1: that's not a question.

2, 9: yes

3, 10: no

4, 11: yes. MinGW includes a tool (dlltool.exe) that takes a .dll and a .def file and creates a .a file MS VisualStudio also includes a tool (that I think is called lib.exe) to do the same thing. And if you start using another compiler you will probably find they have a tool too. Borlands compilers had the implib.exe tool.

5, 12: yes (same as 4)

6, 13: pew... I don't think there is an expiration date on dll's but they must be compiled for the right operating system.

8, 16: you need the .def to make the .a or .lib, if you don't have it, it is actually posible to create that from the .dll