On 4/19/2012 00:16, MARTIN Pierre wrote:
>> Nope, as long as it is in C++, there is no guarantees that it will work
>> with a different compiler. What you could do is to thunk the code via a
>> C bridge from the MSVC side.
>> eg for Simple C++:
>> rettype C_Shutdown(unsigned long a){
>> return Shutdown(a);
>> }
>> and for class/members
>> rettype C_ClassName_MemberFunt(void *C_this, arg1, arg2, ...){
>> ClassName _this = (ClassName)C_this;
>> return _this->MemberFunt(arg1,arg2,..);
>> }
>> and so on. It gets more complicated with virtual/pure functions, you'll
>> need to build a pseudo vtable etc.
> It won't. The API exported by their DLL isn't even object. It looks like pure
> C calls, there are no classes at all. i have no idea why they didn't export
> it "extern C" at the first place.
> You're right that it looks like C calls, you'll have to ask them about it. >> Once you have all the thunk code, compile and link it with MSVC into a >> DLL, you can now use the DLL from mingw-w64 and gendef. > Okay. i have asked the library vendors if they would do that (i won't do it > myself, because their API might be subject to changes, and i'm not going to > do that each time they release). As they are already developping on Windows > with MSVC, it should be a no-brainer for them. > Sure, for them, it'll mostly be another extern "C" interface.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
