Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Compatibility libraries generated by MSVC and minGW
Vics last edited by A Former User
In project I want to use some open source lbraries. It's possible to generate them by Microsoft VC (There are makefiles for MSVC and no makefiles for MinGW).
Also I need use another library. There are makefile for MinGW.
Does all these libraries will compatibility at Qt ? Or I need somehow rebuild libs generated by Microsoft VS by MinGW?
Thanks at advance
yuvaram last edited by
Qt support as single source and can work on different platforms for its dependent compiler.
If your project is building in MSVC then your open source libraries also should be compiled in MSVC.
To add to @yuvaram, on Windows you can't mix and match libraries compiled with different compilers even if they all use Visual Studio. You have to build everything using the same compiler. Thus if any of your dependencies needs a particular version of VS, you have to stay with it.
As for the project handling used, you should rather use qmake or cmake or even qbs. That way you'll be able to generate the adequate build system.
mtrch last edited by
Libraries and application, compiled with different compilers can be mixed if the following conditions are met:
- Library compiled as dynamic link library (DLL)
- It export only plain C API (no classes, function overloading, etc.)
- Memory allocated by DLL must be freed by DLL, not by application. Same for other resources such as files.
- Do not pass CRT handles (for example, FILE* pointer) between DLL and application (WinAPI handles are OK).
- Prefer cdecl calling convention, when exporting symbols from DLL, other conventions can cause trouble, when using MingGW linker.
- ??? (maybe, I forgot something :) )
Memory allocated by DLL must be freed by DLL, not by application. Same for other resources such as files.
This could be relaxed to using the same heap for both binaries, i.e. linking to the same CRT binary.
Do not pass CRT handles (for example, FILE* pointer) between DLL and application (WinAPI handles are OK).
I think the above argument holds here too, but I'm not 100% sure.