RE: Linking egcs built DLL's with MSVC++??

[Paul Herzog <esstech at ess400 dot com>]

>a similar kind of question has been asked several times on
>this list now, but there doesn't seem to be a definitive
>answer yet:
>
>How do I manage to link an egcs-(or gcc) built dll (here: libX11.dll)
>to a C++-mainprog (compiled with MSVC++-5.0) with the MSVC linker ?
>
>- Is it possible at all? If yes, does it also works for C++ objects?
>
>- Which steps are necessary?
>
>Apparently I first need a .lib-file (here: libX11.lib) which the
>MSVC++ linker understands; but how do I generate this?
>When I got the .lib file what else is to be done next?
>
>Many thanks to any help on this matter!
>
>ciao
>  Mark Becker

It should be simple enough to generate a .lib file - just use the lib.exe program provided with msvc, and a suitable .def file:

C:> lib /def:libX11.def

This will generate the files libX11.lib and libX11.exp

Now just use link.exe as usual:

C:>link mainprog.obj another.obj libX11.lib kernel32.lib user32.lib another.lib

// the libraries you actually link with will vary...


One thing i noticed is that if you define your exportable functions using WINAPI
 - which is shorthand for __attribute__ ((stdcall)), that the .def file needs to provide the mangled name for exporting:
for example:

// myProg.c

int WINAPI myFunc(int arg1, int arg2)
{
return arg1 + arg2;
}


// myLib.def

LIBRARY MYLIB
EXPORTS
	myFunc@8


This will create a DLL that exports the name myFunc@8 which refers to the entry point _myFunc@8 which is the mangled name generated by gcc (and cl.exe)

The only downside to this is if you wanted to dynamically load this DLL (using LoadLibrary) and access individual functions in the library using GetProcAddress().  With the .def file as shown above, you would have to supply the mangled export name: "myFunc@8".  If you don't like this (i sure don't...) then you'll need a slightly different .def file
for building the DLL with the gnu tools:

LIBRARY MYLIB
EXPORTS
	myFunc=myFunc@8


This should give you a DLL that exports the symbol myFunc which refers to the entry point _myFunc@8 in myProg.c
The nasty thing here is that when you run lib.exe to create the .lib file, you will need the simpler .def file that doesn't have the "=" in it. Lib.exe doesn't do the right thing with the second .def file, so you'll actually need two versions of the def file. 

While msvc lib.exe and link.exe may not be perfect, the real problem, as far as I can guess, is that dlltool can't associate "myFunc" directly with "_myFunc@8" forcing us to spell it out for dlltool as "myFunc@8".  Dlltool then places "myFunc@8 in the dll export table, rather than myFunc.  When we use the alias feature in the def file, we get "myFunc" in the dll export table as requested.  Now our only aggravation is creating the library files - both dlltool and lib.exe create libraries that associates the symbol myFunc from the dll, with the program reference _myFunc.  Neither gcc nor cl.exe will produce symbols with these names - they produce _myFunc@8.  

So it really is quite messy when you want to support GetProcAddress() nicely.  Indeed, if you are intending to use the DLL with something like VB, or PowerBuilder or most high level tools, they all use GetProcAddress() so you may have to fuss with the def files as described.

Geez, wouldn't it be great if dlltool could handle these WINAPI mangled names more sensibly?

As far as C++ goes, I think you have a harder problem as gcc and cl.exe may not agree on how to mangle class member names - but I have not messed with this myself and can't say for sure.

--
Paul Herzog


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".