Re: [Mingw-users] Linking with Windows VSSAPI.DLL

http://lists-archives.com/mingw-users/05372-linking-with-windows-vssapi-dll.html

notice this part:

Many years ago, I had to interface to a third-party dll forwhich I simply couldn't manage to build an import librarythat worked, despite much effort. So I fell back on what Iguess is the most elementary, brute-force technique, andwrote a '.def' file by hand--and that worked.NAME 'WHATEVER'EXETYPE WINDOWSIMPORTS  _WhateverNameYouWant =GOOFY_DLL.GoofyInternalName  [Snip hundreds of other functions...but you want only one]That was the magic glue that let me call an msvc-builtdll from an application built with a different proprietarycompiler. Later, I rebuilt my application with gcc, creatinga gcc import library this way:libGOOFY_DLL.a: $(some_directory)/GOOFY_DLL.dll GOOFY_DLL.def        $(DLLTOOL) \          --dllname GOOFY_DLL.dll \          --input-def $(src_dir)/GOOFY_DLL.def \          --output-lib libGOOFY_DLL.a

[snip reason for needing to call CreateVssBackupComponents(),which seemingly should have been 'extern "C"' but isn't;assuming that's correct...]> I'm pretty much at a loss how to call this function from MinGW. The only > way I can think of is to write a small wrapper library that I compile with > MSVC, that re-exports this function using extern "C" under a different > name, and link my MinGW code with this wrapper library.Sounds like a good idea, and perhaps the best idea.> However, this is > really ugly because it means I have to call the function with a different > name when using MinGW, and use #define magic to achieve compilation with > both MinGW and MSVC.Maybe the ugliness can be addressed separately: - Call your wrapper, say, DoCreateVssBackupComponents(). - Use your wrapper library, with that function name, for   both gcc and msvc.Or you could add a wrapper for your wrapper:  extern "C" inline void* CreateVssBackupComponents()  {return InternalNameOfWrappedFunction();}but I guess that just moves the ugliness around.I'd be tempted to live with the macro ugliness. Probablyyou do already: e.g., MessageBox() isn't a function, it's amacro that refers to MessageBoxA() or MessageBoxW().> I tried to use dlltool to re-export the symbols from the DLL in an import > library, but 'dlltool --export-all-symbols' on the DLL tells me that no > symbols were found, and creates an import library with no useful symbols. > I haven't tried pexports yet, and I don't know if it can help.Many years ago, I had to interface to a third-party dll forwhich I simply couldn't manage to build an import librarythat worked, despite much effort. So I fell back on what Iguess is the most elementary, brute-force technique, andwrote a '.def' file by hand--and that worked.NAME 'WHATEVER'EXETYPE WINDOWSIMPORTS  _WhateverNameYouWant =GOOFY_DLL.GoofyInternalName  [Snip hundreds of other functions...but you want only one]That was the magic glue that let me call an msvc-builtdll from an application built with a different proprietarycompiler. Later, I rebuilt my application with gcc, creatinga gcc import library this way:libGOOFY_DLL.a: $(some_directory)/GOOFY_DLL.dll GOOFY_DLL.def        $(DLLTOOL) \          --dllname GOOFY_DLL.dll \          --input-def $(src_dir)/GOOFY_DLL.def \          --output-lib libGOOFY_DLL.aand that worked, too. My problem was with a C dll, and Idon't know whether a C++ dll would be more difficult. AndI didn't have msvc, so writing a wrapper library with msvcwasn't an option.But if you already have msvc, then the wrapper approachseems safe, straightforward, and robust; perhaps you'vealready reduced the mess to a minimum with that idea.