Re: [MinGW-dvlpr] C/C++ .dlls

[Mumit K. <khan@NanoTech.Wisc.EDU>]

On Sun, 1 Jul 2001, Paul Garceau wrote:

> 	Here's the hypothetical scenario (think I may have done this sometime 
> in the past, but can't seem to remember the context of it at this 
> time):
> 
> 	I have recently acquired a third-party c++ .dll
> 	I want to dynamically load the third-party .dll for
> 		use under a Mingw c++ application.
> 	I don't have any .a or .def files, only the third-party .dll

No matter what your approach is, the combination above will only work in
a very limited set of cases.

> 	What do I do?
> 
> 		(Here's where I need your feedback)
> 
> 		possible solution (using latest Mingw 1.0 release under Win98)
> 
> 		When linking the mingw c++ application, I use --demangle option which 
> is listed as an option for ld under command.com.  I would do this with 
> the following command line sequence (since there is no make.exe file 
> with Mingw 1.0):
> 
> 		g++ -c myexecutable.cpp -omyexecutable.o
> 		ld myexecutable.o -l3rdprtycpp.dll --demangle -omyexecutable.exe
> 	
> 		What will happen (assuming I have proper command line)?  Any ideas?

Assuming you're using symbols from 3rd party DLL that were linked with the
default C++ linkage, it simply won't work. The demangle option is meant
for something quite different -- to print out human readable symbol names
when ld can't resolve C++ which are mangled.

This has been hashed over before, but given the volume of questions on
this, it probably bears repeating. You cannot mix and match code produced
by different C++ compilers, or even different versions of the same
compiler, unless the compilers use the same Application Binary Interface
(ABI). Currently I don't know of any two major C++ compilers that share the
same ABI (exceptions are those that use the same C++ front-end, such as
the EDG front-end, but even then it's not guaranteed by any means; there
may also be other vendors that try to be MSVC ABI compatible).

The only case where it may work is the following: let's say your client
code, compiled with C++ compiler A, is going to use link with 3rd party
DLL, compiled with C++ compiler B. It *may* work *iff* the functions your
client code uses from 3rd party DLL use *C linkage*. 

Let's please close this thread, and not reopen until and unless GNU
and Microsoft start using the same C++ ABI, which is highly unlikely to 
ever happen, patent restrictions being one of the many reasons.

Regards,
Mumit