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

[Greg C. <chi...@co...>]

On 2006-12-4 22:26 UTC, Chris Wilson wrote:

[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. Probably
you do already: e.g., MessageBox() isn't a function, it's a
macro 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 for
which I simply couldn't manage to build an import library
that worked, despite much effort. So I fell back on what I
guess is the most elementary, brute-force technique, and
wrote a '.def' file by hand--and that worked.

NAME 'WHATEVER'
EXETYPE WINDOWS
IMPORTS
  _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-built
dll from an application built with a different proprietary
compiler. Later, I rebuilt my application with gcc, creating
a 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

and that worked, too. My problem was with a C dll, and I
don't know whether a C++ dll would be more difficult. And
I didn't have msvc, so writing a wrapper library with msvc
wasn't an option.

But if you already have msvc, then the wrapper approach
seems safe, straightforward, and robust; perhaps you've
already reduced the mess to a minimum with that idea.