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 option for a compiler.
The problem is that many 3rd party libraries that I've tried do not seem to work.

I am new to .dll, .a, .lib, .def files and library schemes.

Question 1:

In my limited experience (I've tried 7 or 9 libraries so far), suppliers of libraries seldom tell you whether the .dll was made with VisualStudio or gcc. This adds a lot of confusion. They almost never make it clear what compiler the library is compatible with. So I would appreciate some real life tips of how to deal with this nightmare. Almost all the libraries I tried are OpenSource projects. I won't name names here, but these are well known projects. I'm sure the problem is my lack of knowledge...

MinGW and gcc World

Question2:
As far as I can tell, dynamic C++ libraries for MinGW gcc universe require these, right?
*.h
*.dll
*.a

Question 3:
Unfortunately, the .a file is often missing and the library does not work. This is very confusing. If the .a file is missing am I out of luck?

Question 4:
Can I generate the .a file for MinGW/gcc if the *.dll was made with gcc?

Question 5: Can I generate the .a file for MinGW/gcc if the *.dll was made with VisualStudio?

Question 6:
Is it possible that a *.dll (made with MinGW/gcc) is too old and no longer compatible with newer MinGW/gcc?

Question 7:
Qt projects using MinGW/gcc never need *.lib files, right? That is a VisualStudio only thing, right?

Question 8:
I don't need a *.def file to use a *.dll in a Qt projects using MinGW/gcc, right?

VisualStudio World

Question 9:
As far as I can tell, dynamic C++ libraries for VisualStudio require these:
*.h
*.dll
*.lib

Right? Again, the problem is that the *.lib file is almost always missing. Plus, no clear instructions about what compiler the library is compatible with. So how can I know that it is for VisualStudio only or not?

Question 10:
If the .lib file is missing am I out of luck?

Question 11:
Can I generate the .lib file for VisualStudio if the *.dll was made with VisualStudio? How?

Question 12:
Can I generate the .lib file for VisualStudio if the *.dll was made with MinGW/gcc? How?

Question 13:
Is it possible that a *.dll (made with VisualStudio) is too old and no longer compatible with newer VisualStudio?

Question 14:
If in QtCreator I select the VisualStudio compiler, is that 100% compatible with dynamic libraries compiled with REAL VisualStudio by someone else? I believe the VisualStudio compiler option in Qt Creator is a fake VisualStudio compiler.

Question 15:
If in QtCreator I select the MinGW/gcc compiler, can I use with Qt dynamic libraries compiled with REAL VisualStudio by someone else?

Question 16:
I don't need a *.def file to use a *.dll in a Qt projects using MinGW/gcc, right?

Question 17: Can I convert a *lib (that works with a *.dll and *.h) file made with REAL VisualStudio to a *.a file so I can use the *.a file with the unmodified *.dll, and *.h files in a Qt gcc project?

Answer 1

I know it is an old question, yet I have had a similar problems recently.

In addition to Lars Betak's answer above please note that calling pure C DLL can produce very strange results if both sides are not complied with the same Standard Library. GCC and MSVC stdlibs are definitely different.

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

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

Answer 4

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 5

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.