How to Use Libraries Compiled with Mingw in Msvc

How to use libraries compiled with MingW in MSVC?

Based on this error you put in a comment:

error LNK2019: unresolved external
symbol "int __cdecl
openssl_call(struct ssl_State
*,int,int,int)" (?openssl_call@@YAHPAUssl_State@@HHH@Z)
referenced in function _main MyAPP.obj
all other 4 errors are same only with
other functions names

Try putting extern "C" around your include files for openssl. For example:

extern "C" {
include "openssl.h"
}

using extern "C" will instruct the compiler that the functions are using C linkage, not C++, which will stop it from performing name mangling on the functions. So it will look for the function openssl_call in the library rather than ?openssl_call@@YAHPAUssl_State@@HHH@.

Do libraries compiled with MinGW work with MSVC?

No, libraries compiled on MinGW can't be used with MSVC. The main reasons are:

• Lack of ABI compatibility. That is to say that in binary, the way things can be laid out are different depending on the compiler.
• Difference in how the standard library is implemented. The standard library can be implemented in many ways. The C++ Standard just says how functions should behave and does not force compiler developers to implement them in the same way.

In general, things compiled with one compiler aren't compatible with another compiler.

Linking a MinGW library to a MSVC app with a C interface

I figured out what works for me, so I'll share.

I was not able to link a static library between compilers as I originally attempted. My understanding is that the extra info kept in the lib to allow link-time code generation is compiler-specific. Brecht Sanders's answer outlines a few possible reasons why the code wouldn't be compatible.

I was, however, able to link to a shared library, with a few extra steps.

Using the same suite (see the question), I compiled as shared and got libopenal.dll, libopenal.dll.a, and libopenal.def. In my case, the .def file was generated by the suite. Accoding to this answer, you can generate a .def file with gcc using:

gcc -shared -o your_dll.dll your_dll_src.c -Wl,--output-def,your_dll.def

Trying to link to libopenal.dll.a still gave me errors (I don't know exactly why, and I already discarded the logs.) What I did instead was generate a .lib file from the .def file. In Visual Studio's built-in terminal:

lib /machine:x64 /def:libopenal.def

This generated a libopenal.lib file in the working directory. Linking to this file worked perfectly, and I was able to successfully load the dll at runtime.

I've tested this same method with many other MinGW-compiled libraries from the suite, including libavformat, libavcodec, libavutil, libavdevice, swresample, and swscale, and thus far all of them have worked.

Kind of convoluted, but it seems to work well for me, so I hope this helps anyone else with the same problem.

Compiling and linking library MSVC/MingW

if you have experience with CMake, create your own CMakeLists file and import/link this libraries against your project. In this way, you can create projects for MinGW/MSVC/Linux/etc.

Here you'll find a good start with CMake http://www.cmake.org/cmake-tutorial/

Use libraries compiled with visual studio in an application compiled by g++ (mingw)

• If the library is written in C++ and exposes a C++ interface: no (because the name-mangling differs between g++ and VC++).

• If the library is a static library written in C (or with an extern "C" interface): yes, but certain caveats apply.

• If the library is a DLL with a C interface: yes, but you'll have to create your own import library.

Linking to MSVC DLL from MinGW

You can't do this. They have exported C++ classes from their dll, rather than C-functions. The difference is, c++ functions are always exported with names in a mangled form that is specific to a particular version of the compiler.

Their dll is usable by msvc only in that form, and will probably not even work between different versions of msvc, as Microsoft have changed their mangling scheme before.

If you have any leverage, you need to get them to change their evil ways. Otherwise you will need to use MSVC to write a shim dll, that will import all the classes, and re-export them via c functions that return interfaces.

---

Related Topics