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

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

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