Mixing Compilers

rubenvb
2010-06-03
2013-06-06
  • rubenvb
    rubenvb
    2010-06-03

    I apologize if this has been asked before, but…
    Is it possible to use a mingw-w32/w64 dll, create a *.lib and link it with msvc 8/9/10? And vice versa? I noticed several things here going in that direction (libmangle, gendef, the underscoring fix), and would think it should be quite possible.

    I've been reading the mingw-users archives, and dang are they b*tchy to everyone that asks a normal question… Thet seem to say it is impossible

    Thanks!

    PS: if this is possible, it should be marketed as an advantage of this toolchain :) Heck, how does one market an Open Source program, if not by mouth-to-mouth advertisement…

     
  • Doug Semler
    Doug Semler
    2010-06-03

    The question is really difficult to answer, because really, the answer is "it depends."

    In general, interoperability works when linking DLLs from one compiler into another.  Static libraries work pretty much only if there are no dependencies on the CRT (either way).  This is pretty much due to the "behind the scenes" stuff that we (and MSVC) insert during link time to "make it all work."  In other words, the static library pretty much has to be self contained for the link to work right.  Even then, there's no guarantee because there still may be some implicit things brought in.

    In addition, the following caveats apply right now:
    x64 linkages will not work unless you are using the latest underscoring behavior toolchains.  This means gcc 4.5+, binutils from cvs (I don't remember offhand the required revision), AND the trunk CRT built with them.

    Using MSVC to link against gcc compiled dynamic libraries does not yet work out of the box.  I have patches for binutils that are in the pipeline to allow this to occur; but I am having difficulty with my employer disclaimer for the copyright assignment (there's a lot of back and forth and it's a pain).  Until they get posted upstream, I have the patches at http://github.com/tpaxatb/buildscripts/tree/master/binutils-patches/ and now that I have write access to svn I'll place them in the experimental source directory when I get a chance.  I believe that Ozkan's current builds (I think) have these patches applied as well.

    Using gcc to link against dynamic libraries built by MSVC works on everything I've tested.  In fact, current heads allow linking directly against a DLL (no import library needed) alot of the time :)

    C++ is a "don't bother" unless you are linking against extern "C".  There's a reason that the name mangling is different: there is no guarantee any of the layouts between compilers are the same.

    I really don't know about fortran -- i am assuming that following C linkage would give you the same results as above.

    Exceptions probably won't work as expected if crossing boundaries due to the way that we implement them.

    DLL DATA exports that are thread local will not be imported properly by the other compiler due to the differences in how they are implemented (gcc has an emulation layer, which obviously msvc doesn't use).

    That's all I can think of for now…
    Doug.

     
  • Ozkan Sezer
    Ozkan Sezer
    2010-06-03

    > toolchains.  This means gcc 4.5+, binutils from cvs (I don't remember offhand

    Or 4.4 with suitable backports of stuff as in my personal builds.

    > the required revision), AND the trunk CRT built with them.

    No, this is not correct: There is nothing in the way of crt from the v1.0 branch to interoperate with msvc if it is compiled using the latest compiler sets.

     
  • Doug Semler
    Doug Semler
    2010-06-03

    > the required revision), AND the trunk CRT built with them.
    No, this is not correct: There is nothing in the way of crt from the v1.0 branch to interoperate with msvc if it is compiled using the latest compiler sets.

    I stand corrected…I wasn't sure if all the underscoring hooks were in the v1.0 branch :)

     
  • rubenvb
    rubenvb
    2010-06-03

    That's what I thought. Why do the mingw.org people do so difficult about it? They literally say "it ain't gonna happen", and you guys say: "probably, with a few caveats" :)

     
  • Doug Semler
    Doug Semler
    2010-06-03

    Well, FWIW, the caveats in the url you provided also apply to us (and most of the things I stated are in there anyway).

    I think the biggest difference is that the mingw.org folks state, "We don't support it," because they don't want to spend the time to support it or look into it.  It's a lot easier to say "you're on your own" that way.
    I think we pretty much say, "It may or may not work.  If it doesn't work let us know and we'll look into it if and when we get a chance.  However, there's no guarantee that we can make it work, but at least we'll try to tell you why it doesn't work."  (well, ok, I'm using the "Royal We" there ;-)…I can't speak for the other devs hehe….)

     
  • rubenvb
    rubenvb
    2010-06-03

    I gotcha. IMHO this is a healthy stance towards users and features :) Keep it up!

     
  • Kai Tietz
    Kai Tietz
    2010-06-03

    In fact we try to provide as much possiblities for providing at least the chance to mix different compilers. I fully agree to the statement tpaxatb did here. For example in upcoming 4.6 gcc we added the missing calling-convention __thiscall, which is essencial for being able to link and call VC generated C++ class-methods. Additional we added for this the additional aliasing feature to ld/dlltool '==', which allows to rename a symbol exported by a DLL under a different name. All those are steps to provide more compatibility, or at least abilities, between gcc/binutils and VC generated code.
    If you look onto our Wiki-Page for planned TODOs, you will find additional feature we plan to improve this.

    Kai