Linking to MinGW lib from vs2005

This is a discussion on Linking to MinGW lib from vs2005 within the Tech Board forums, part of the Community Boards category; kennedy != C++ Attempting to help someone out. I had this problem when attempting to link to a Windows dll ...

  1. #1
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065

    Linking to MinGW lib from vs2005

    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!

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,676
    >> 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

  3. #3
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    LoadLibrary()
    GetProcAddress()

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

    Code:
    // 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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  4. #4
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    >>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

  5. #5
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,676
    >> 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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 15
    Last Post: 08-16-2009, 10:49 AM
  2. Replies: 3
    Last Post: 04-16-2007, 12:02 PM
  3. MinGW Linking GUI Program
    By Tonto in forum Tech Board
    Replies: 19
    Last Post: 08-23-2006, 03:28 PM
  4. (quick and easy) lib linking question
    By cjschw in forum C++ Programming
    Replies: 4
    Last Post: 09-01-2004, 06:04 PM
  5. Convert Microsoft LIB to MingW compatible lib
    By tigs in forum Windows Programming
    Replies: 0
    Last Post: 07-20-2004, 06:53 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21