This is the mail archive of the
mailing list for the Cygwin project.
RE: Dll linking problem
- From: "Schaible, Jörg" <Joerg dot Schaible at gft dot com>
- To: <cygwin at cygwin dot com>
- Date: Fri, 30 Aug 2002 16:14:21 +0200
- Subject: RE: Dll linking problem
> A dll written using VC++ environment is exporting a complete class.
> The same is being accessed through cygwin, but it is unable to link to
> the class functions.
> However if the functions are declared inline in the dll, cygwin
> application is able to link successfully with the class functions.
> The same dll can be accessed successfully through a program written in
> VC++ environment.
> Please let me know if anyone can suggest an analysis or a solution.
Since the functions are inline, every compilation unit has its own version and the linker removes any duplicates for the execution unit. If the compiler is smart enough (or the functions easy enough) the code of the function is included everywhere the inlined function is called increasing space gaining speed. The result is either no explicit function at all (because the code is "inlined") or each execution unit (dll or executable) has its own set of functions.
You will get problems if not all of the functions are inline or the compiler ignores the "inline" (which is just a suggestion for the compiler, no strict commend). If one function is not inline, the linker will try to call the function in the DLL which fails, since the linker symbol generation of C++ symbols is not standardized (well, not only the name, but also at which position the implicit "this" parameter is provided, how the internal data layout for the class is realized and how the vtable is implemented). Another problems are thrown execptions from the DLL. There is also no standardized way how they are implemented. The standard just defines how they have to work!
==> DO NOT TRY LINK C++ DLL's FROM DIFFERENT COMPILERS!
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html