[Question] Linking MSVC libraries against MinGW

[ManasJayanth]

Can flexlink link MinGW and MSVC libraries to produce and exe/dll?

We are trying to write bindings for Skia (https://github.com/manuhornung/reason-skia) and the it is recommended that we built Skia with MSVC on Windows (we are exploring mingw too)

Our first attempts were to compile the bindings with the mingw toolchain given the ecosystem support it has. To test these bindings we link the bindings into a test binary too (https://github.com/manuhornung/reason-skia/tree/master/bin_native)

Keeping in mind that the Skia library itself is an MSVC COFF, and that the bindings are being compiled with MinGW toolchain, I faced issues at two levels.

Compiling and linking the test binary with MinGW backed compiler, flexlink complained about unresolved MSVC symbols

** Cannot resolve symbols for C:\Users\manas\development\reason-skia\_esy\default\store\b\reason_skia-84a967d7\default\src\skia.lib(skia.obj):
 ??0SkFILEWStream@@QEAA@QEBD@Z
 ??0SkFont@@QEAA@V?$sk_sp@VSkTypeface@@@@MMM@Z
 ??0SkPaint@@QEAA@XZ
??0SkSurfaceProps@@QEAA@IW4SkPixelGeometry@@@Z

Those symbols are from skia.cpp stubs in reason-bindings

On trying to link with flexlink compiled with MSVC toolchain, I faced the following

** Cannot resolve symbols for C:\users\manas\development\flexdll\flexdll_msvc.obj:
 _memcpy
 _strcmp
 _strlen
** Cannot resolve symbols for C:\Users\manas\.esy\3_\i\ocaml-4.6.10-7ba95816\lib\ocaml\libasmrun.a(floats.o):
 __strtod
Fatal error: exception Failure("Unsupported relocation kind 0004 for __strtod in C:\\Users\\manas\\.esy\\3_\\i\\ocaml-4.6.10-7ba95816\\lib\\ocaml\\libasmrun.a(floats.o)")

I did so by cloning and checking out latest stable tag, and simply ran the linking subcommand that ocamlopt uses on Windows. Note that it is still the MinGW built OCaml compiler. So flexlink failed to link the MinGW archive against skia.lib (MSVC COFF)

1. Does flexlink account for any kind of binary compatibility so that it can link the two libraries (from different compilers). I understand the chances are slim and MinGW itself very vaguely says yes.

2. Is flexlink absolutely necessary for ocamlopt on Windows even for static linking?

3. Is it wrong to expect flexlink to link MinGW and MSVC libraries together? And that we should have used a the compiler built with MSVC toolchain from the get-go?

[alainfrisch]

Even if the file formats are the same, I don't think it is realistic to link (statically) objects or libraries produced by both MSVC and mingw.

[ManasJayanth]

Reposting incase you missed it: Is flexlink absolutely necessary for ocamlopt on Windows even for static linking?

[alainfrisch]

The current build system assumes flexlink is avalaible, but people have managed to build without it, with only little tweaks. cc @damiendoligez @dra27 who might provide some info.

[jordwalke]

@alainfrisch When you say that it is not realistic to link objects or libraries produced by MSVC and mingw, do you mean it's not realistic for flexdll to work with them? I heard that mingw compiler now supports linking libraries produced by MSVC. Are you saying that flexdll is the thing that does not work in this case?

[alainfrisch]

"Not realistic" was perhaps an over-statement. I should have say that my intuition is that this would be difficult to be made to work in practice with reasonable efforts. I can actually think of some reasons that would make this difficult (such as the C compiler generating calls to specific functions to be provided by the libc, e.g. for floating point opeations, things related to exception handling, etc); enough so that I don't want to create false hopes. But if you want to give it a try, go ahead.

[ManasJayanth]

Thanks for elaborating that for us @alainfrisch I'm keeping this issue open purely for some information regarding the flexlink workaround I asked for earlier.

Having a workaround for flexlink would help me understand if flexlink causing issues or my setup. I'm shelving the MinGW-MSVC hybrid approach for now. But despite being on the MSVC switch on fdopen's opam, I'm still facing those linker issues. So, the flexlink alternative would still help.

[dra27]

IIRC It's not possible at present to build native Windows OCaml without the shared support - it's integral to how an ocamlopt-compiled program finds the symbols in asmrun. In order to build an OCaml without it, it'd be necessary to resurrect the DLL-support.

[ManasJayanth]

Appreciate the pointer, @dra27 . Closing this for now. I hope it's okay to re-open this thread in future if I have more querries. Thank you 🙂