Linking to MinGW lib from vs2005

[Kennedy]

kennedy != C++

Attempting to help someone out. I had this problem when attempting to link to a Windows dll from MinGW, but now we are going from vs2005 to MinGW.

Anyone have any experience with this? Anyone know the gotcha's that we'll face and how to overcome those?

Really, I don't have much information other than we get a runtime error where the heap gets trashed whilst attempting to load the DLL (this is a static link we're doing). I also know that we're using vs2005's libtool.exe to make a static library to link at compile time.

Again, kennedy has no class. . . doesn't want class. . . doesn't need two bug eyes either OO . . . but does need some help if you'd be so kind as to do so (that bug eyes thing would be a joke/reference to Ghost Busters).

Thanks in advance!

[Codeplug]

>> we're using vs2005's libtool.exe to make a static library
You mean you're using lib.exe to create a static import library with a .DEF file - correct?

So you have a MinGW built DLL, that you wish to use from within a module being built by VS2005 - correct?

What does the MinGW built DLL expose? C functions? C++ function? C++ classes?

Does the MinGW DLL use any CRT features (malloc, free, any C-runtime stuff)?
Does it pass any CRT-type objects across DLL boundaries (like FILE handles or even STL objects).

STL usage should be completely isolated within the DLL since MinGW and VS have their own separate implementations. In other words, you can't pass std::string, std::vector, etc. across the DLL boundary.

Ideally, CRT usage should be completely isolated within the DLL as well. Otherwise, both the DLL and client need to be using the exact same CRT DLL version. By default, MinGW uses MSVCRT.dll. If both DLL and client are not using the same CRT DLL, then for example, calling malloc() in the DLL and free() in the client isn't going work. MinGW can link with newer versions of the CRT, but it's better to make you DLL interface CRT/STL agnostic.

gg

[abachler]

LoadLibrary()
GetProcAddress()

and dont forget to declare the functions you will be calling liek such

// A simple program that uses LoadLibrary and 
// GetProcAddress to access myPuts from Myputs.dll. 
 
#include <windows.h> 
#include <stdio.h> 
 
typedef int (__cdecl *MYPROC)(LPWSTR); 
 
VOID main(VOID) 
{ 
    HINSTANCE hinstLib; 
    MYPROC ProcAdd; 
    BOOL fFreeResult, fRunTimeLinkSuccess = FALSE; 
 
    // Get a handle to the DLL module.
 
    hinstLib = LoadLibrary(TEXT("MyPuts.dll")); 
 
    // If the handle is valid, try to get the function address.
 
    if (hinstLib != NULL) 
    { 
        ProcAdd = (MYPROC) GetProcAddress(hinstLib, "myPuts"); 
 
        // If the function address is valid, call the function.
 
        if (NULL != ProcAdd) 
        {
            fRunTimeLinkSuccess = TRUE;
            (ProcAdd) (L"Message sent to the DLL function\n"); 
        }
        // Free the DLL module.
 
        fFreeResult = FreeLibrary(hinstLib); 
    } 

    // If unable to call the DLL function, use an alternative.
    if (! fRunTimeLinkSuccess) 
        printf("Message printed from executable\n"); 
}

and dotn froget to FreeLibrary() when you are finished.

[Kennedy]

>>You mean you're using lib.exe to create a static import library with a .DEF file - correct?

Yes.

>> So you have a MinGW built DLL, that you wish to use from within a module being built by VS2005 - correct?

Correct.

>> What does the MinGW built DLL expose? C functions? C++ function? C++ classes?

C++ classes et al

>> Does the MinGW DLL use any CRT features (malloc, free, any C-runtime stuff)?
Does it pass any CRT-type objects across DLL boundaries (like FILE handles or even STL objects).

The dll does do a massive malloc and free for reading in a large file (4MB) full of XML crap. The runtime error that we are getting has to do with that (but the programmer that made that dll says "it works everywhere else, you just need to update to vs2008", though the code was working in vs2005 within the last two months).

>> STL usage should be completely isolated within the DLL since MinGW and VS have their own separate implementations. In other words, you can't pass std::string, std::vector, etc. across the DLL boundary.

-- kennedy != C++ (man, that up there sounds like Charlie Brown's teacher, and I don't have the time to go searching around through google, so, I'll remain ignorant) -- I know that we are attempting to pass strings, but I think that the strings are wchar strings, not std strings (if what I'm saying even makes sense).

>> Ideally, CRT usage should be completely isolated within the DLL as well. Otherwise, both the DLL and client need to be using the exact same CRT DLL version. By default, MinGW uses MSVCRT.dll. If both DLL and client are not using the same CRT DLL, then for example, calling malloc() in the DLL and free() in the client isn't going work. MinGW can link with newer versions of the CRT, but it's better to make you DLL interface CRT/STL agnostic.

Okay, this may be the hint that we needed. I'll pass this one along. If you have anything else on it, please let me know.

Thanks,
Andy

[Codeplug]

>> C++ classes et al
That has it's own set of issues - but mostly to do with linking. So you if you have a working .DEF file and no linking issues, then I'll assume that all names are "hooked up" correctly and using the correct calling convention.

More info on mixing C++ between compilers: Binary-compatible C++ Interfaces

gg