Thread: RE: [Dev-C++] Couldn`t link MinGW DLL to MSVC program
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: <Mat...@Ve...> - 2005-04-12 16:37:12
|
My understanding was that compilers don't mangle C names in libraries, only
C++ ones.
Now I'm really confused!
-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of Gerson
Lara
Sent: Monday, April 11, 2005 11:39 PM
To: DEV
Subject: Re: [Dev-C++] Couldn`t link MinGW DLL to MSVC program
I have successfuly tested creating "dummy" dll with DEV-C++ 4.0 and using
them in VisualBasic 6.0,
the thing is the famous namemangling, what I do is looking at a .def file
that [i think] dllwrap
or dlltool creates in the same directory of the DLL. Finally, in VB I dont
use the same name that
in my C code, instead, I Use the mangled names that I obtain from the .def
file. May be that helps
just a little.
NOTE: this is valid for C code, if I try with C++ code [classes] the name
mangling turns too
confusing for me...
Hope This Helps...
--- Per Westermark <pw...@ia...> escribi=F3:=20
> It is possible to create DLL files exporting variables and functions -
> using "C" naming convention and mix between gcc and M$. However, you can't
> export/import classes or other C++ symbols (and often not structs either),
> since the C++ mangling - and the internal memory layout - is different
> between the compilers.
>=20
> Google on ABI (Application Binary Interface) and you will get more
> information about the problem.
>=20
> /Per W
>=20
> On Sun, 27 Mar 2005, Dmitry Sidorov wrote:
>=20
> > Hello dev-cpp-users.
> >
> > I have the following source files to build DLL with Dev-Cpp
> >
> >
> > // dll.h
> > #ifndef _DLL_H_
> > #define _DLL_H_
> >
> > #if BUILDING_DLL
> > # define DLLIMPORT __declspec (dllexport)
> > #else /* Not BUILDING_DLL */
> > # define DLLIMPORT __declspec (dllimport)
> > #endif /* Not BUILDING_DLL */
> >
> > class DLLIMPORT MyClass
> > {
> > public:
> > MyClass();
> > virtual ~MyClass(void);
> > };
> > #endif /* _DLL_H_ */
> >
> >
> > // dllmain.cpp
> > #include "dll.h"
> > #include <windows.h>
> >
> > MyClass::MyClass()
> > {
> > MessageBox( NULL, "MyClass construccted!!!", "test", 0 );
> > }
> > MyClass::~MyClass()
> > {
> > }
> > BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle.
*/ ,
> > DWORD reason /* Reason this function is
being called. */ ,
> > LPVOID reserved /* Not used. */ )
> > {
> > switch (reason)
> > {
> > case DLL_PROCESS_ATTACH:
> > break;
> >
> > case DLL_PROCESS_DETACH:
> > break;
> >
> > case DLL_THREAD_ATTACH:
> > break;
> >
> > case DLL_THREAD_DETACH:
> > break;
> > }
> >
> > /* Returns TRUE on success, FALSE on failure */
> > return TRUE;
> > }
> >
> > This is standard DLL project of Dev-Cpp with MessageBox function in
> > MyClass constructor
> >
> > I build DLL with Dev-Cpp and then build .LIB file by LIB.exe from the
> > MSVC installation.
> >
> > lib.exe /machine:i386 /def:libhellodll.def
> >
> > Then I create the following code in MSVC
> > // testdll.cpp : Defines the entry point for the console application.
> > //
> > #include "stdafx.h"
> > #include "dll.h"
> >
> > int _tmain(int argc, _TCHAR* argv[])
> > {
> > MyClass hello;
> > return 0;
> > }
> >
> > I also add libhellodll.lib to MSVC project
> > But when my testdll is linking I got the following errors
> >
> > testdll2 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __thiscall
> MyClass::MyClass(void)" (__imp_??0MyClass@@QAE@XZ) referenced in function
_main
> > testdll2 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: virtual
> __thiscall MyClass::~MyClass(void)" (__imp_??1MyClass@@UAE@XZ) referenced
in function _main
> > testdll2 fatal error LNK1120: 2 unresolved externals
> >
> >
> > Then I tried to use dlltool from MinGW
> > dlltool.exe -d libhellodll.def --dllname hellodll.dll --output-lib
libhellodll.lib
> >
> > But I`ve got the same error
> > I also tried to use dlltool.exe with -U and -k flags, I`ve got the
> > same errors :(
> >
> > Can anybody help me?
> > Excuse me for my poor english
> >
> > --
> > Dmitry
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> =20
=09
______________________________________________=20
Renovamos el Correo Yahoo!: =A1250 MB GRATIS!=20
Nuevos servicios, m=E1s seguridad=20
http://correo.yahoo.es
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure. If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof. Thank you.
|
|
From: <Mat...@Ve...> - 2005-04-13 19:58:56
|
Thanks for the heads-up, Per. I was getting really confused before, hehe! -----Original Message----- From: Per Westermark [mailto:pw...@ia...] Sent: Wednesday, April 13, 2005 12:57 PM To: Mat...@Ve... Cc: ja...@ya...; dev...@li... Subject: RE: [Dev-C++] Couldn`t link MinGW DLL to MSVC program That is correct - no name mangling for C. But you may still get some extra characters in the names. The normal is that you get a leading '_' for all external C symbols but to my knowledge there exists environments where a '$' first or last might be used. The leading '_' was added to place the C symbols in their own "namespace" to avoid name collisions with operating system symbols, i.e. open is a OS function while _open is the function available in the C standard library and called by the C code. /Per W ___________________________________________________________________ The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. |
|
From: Per W. <pw...@ia...> - 2005-04-13 20:24:23
|
One addendum. The C++ standard requires name mangling, since the language support multiple functions with the same name but different parameter signatures, such as: int add(int a,int b); doule add(double a,double b); Complex& add(Complex& a,Complex& b); C compilers knows that functions already have unique names, so they can ignore parameter count, parameter types etc. However, some compilers can add extra name mangling to mark functions compiled with non-compatible calling conventions. If you build one C file with all functions taking the parameters in processor registers and a second C file with all functions sent on the stack, a program would fail if a function in one file calls a function in the other file. If the compiler for example adds a $ at the end of the names of all functions built with register calling convention, then the linker will automatically fail to link such a program and you avoid creating a badly broken application. So in short - there _can_ exist C name mangling, but it is for a different reason and it isn't because of parameter count/types but to detect incompatible compiler optimization rules. Some of these compilers have also added non-standard keywords to for example specify: __regcall int add(int a,int b); to inform that a specific function has a specific calling convention different from the one used in the normal C libraries. /Per W On Wed, 13 Apr 2005 Mat...@Ve... wrote: > Thanks for the heads-up, Per. I was getting really confused before, hehe! > > -----Original Message----- > From: Per Westermark [mailto:pw...@ia...] > Sent: Wednesday, April 13, 2005 12:57 PM > To: Mat...@Ve... > Cc: ja...@ya...; dev...@li... > Subject: RE: [Dev-C++] Couldn`t link MinGW DLL to MSVC program > > > That is correct - no name mangling for C. But you may still get some extra > characters in the names. The normal is that you get a leading '_' for all > external C symbols but to my knowledge there exists environments where a > '$' first or last might be used. The leading '_' was added to place the C > symbols in their own "namespace" to avoid name collisions with operating > system symbols, i.e. open is a OS function while _open is the function > available in the C standard library and called by the C code. > > /Per W |
|
From: Per W. <pw...@ia...> - 2005-04-13 19:57:26
|
That is correct - no name mangling for C. But you may still get some extra
characters in the names. The normal is that you get a leading '_' for all
external C symbols but to my knowledge there exists environments where a
'$' first or last might be used. The leading '_' was added to place the C
symbols in their own "namespace" to avoid name collisions with operating
system symbols, i.e. open is a OS function while _open is the function
available in the C standard library and called by the C code.
/Per W
On Tue, 12 Apr 2005 Mat...@Ve... wrote:
> My understanding was that compilers don't mangle C names in libraries, on=
ly
> C++ ones.
>
> Now I'm really confused!
>
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of Gerson
> Lara
> Sent: Monday, April 11, 2005 11:39 PM
> To: DEV
> Subject: Re: [Dev-C++] Couldn`t link MinGW DLL to MSVC program
>
>
> I have successfuly tested creating "dummy" dll with DEV-C++ 4.0 and using
> them in VisualBasic 6.0,
> the thing is the famous namemangling, what I do is looking at a .def file
> that [i think] dllwrap
> or dlltool creates in the same directory of the DLL. Finally, in VB I don=
t
> use the same name that
> in my C code, instead, I Use the mangled names that I obtain from the .de=
f
> file. May be that helps
> just a little.
> NOTE: this is valid for C code, if I try with C++ code [classes] the name
> mangling turns too
> confusing for me...
> Hope This Helps...
>
> --- Per Westermark <pw...@ia...> escribi=F3:
> > It is possible to create DLL files exporting variables and functions -
> > using "C" naming convention and mix between gcc and M$. However, you ca=
n't
> > export/import classes or other C++ symbols (and often not structs eithe=
r),
> > since the C++ mangling - and the internal memory layout - is different
> > between the compilers.
> >
> > Google on ABI (Application Binary Interface) and you will get more
> > information about the problem.
> >
> > /Per W
> >
> > On Sun, 27 Mar 2005, Dmitry Sidorov wrote:
> >
> > > Hello dev-cpp-users.
> > >
> > > I have the following source files to build DLL with Dev-Cpp
> > >
> > >
> > > // dll.h
> > > #ifndef _DLL_H_
> > > #define _DLL_H_
> > >
> > > #if BUILDING_DLL
> > > # define DLLIMPORT __declspec (dllexport)
> > > #else /* Not BUILDING_DLL */
> > > # define DLLIMPORT __declspec (dllimport)
> > > #endif /* Not BUILDING_DLL */
> > >
> > > class DLLIMPORT MyClass
> > > {
> > > public:
> > > MyClass();
> > > virtual ~MyClass(void);
> > > };
> > > #endif /* _DLL_H_ */
> > >
> > >
> > > // dllmain.cpp
> > > #include "dll.h"
> > > #include <windows.h>
> > >
> > > MyClass::MyClass()
> > > {
> > > MessageBox( NULL, "MyClass construccted!!!", "test", 0 );
> > > }
> > > MyClass::~MyClass()
> > > {
> > > }
> > > BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle=
=2E
> */ ,
> > > DWORD reason /* Reason this function is
> being called. */ ,
> > > LPVOID reserved /* Not used. */ )
> > > {
> > > switch (reason)
> > > {
> > > case DLL_PROCESS_ATTACH:
> > > break;
> > >
> > > case DLL_PROCESS_DETACH:
> > > break;
> > >
> > > case DLL_THREAD_ATTACH:
> > > break;
> > >
> > > case DLL_THREAD_DETACH:
> > > break;
> > > }
> > >
> > > /* Returns TRUE on success, FALSE on failure */
> > > return TRUE;
> > > }
> > >
> > > This is standard DLL project of Dev-Cpp with MessageBox function in
> > > MyClass constructor
> > >
> > > I build DLL with Dev-Cpp and then build .LIB file by LIB.exe from the
> > > MSVC installation.
> > >
> > > lib.exe /machine:i386 /def:libhellodll.def
> > >
> > > Then I create the following code in MSVC
> > > // testdll.cpp : Defines the entry point for the console application.
> > > //
> > > #include "stdafx.h"
> > > #include "dll.h"
> > >
> > > int _tmain(int argc, _TCHAR* argv[])
> > > {
> > > MyClass hello;
> > > return 0;
> > > }
> > >
> > > I also add libhellodll.lib to MSVC project
> > > But when my testdll is linking I got the following errors
> > >
> > > testdll2 error LNK2019: unresolved external symbol
> "__declspec(dllimport) public: __thiscall
> > MyClass::MyClass(void)" (__imp_??0MyClass@@QAE@XZ) referenced in functi=
on
> _main
> > > testdll2 error LNK2019: unresolved external symbol
> "__declspec(dllimport) public: virtual
> > __thiscall MyClass::~MyClass(void)" (__imp_??1MyClass@@UAE@XZ) referenc=
ed
> in function _main
> > > testdll2 fatal error LNK1120: 2 unresolved externals
> > >
> > >
> > > Then I tried to use dlltool from MinGW
> > > dlltool.exe -d libhellodll.def --dllname hellodll.dll --output-lib
> libhellodll.lib
> > >
> > > But I`ve got the same error
> > > I also tried to use dlltool.exe with -U and -k flags, I`ve got the
> > > same errors :(
> > >
> > > Can anybody help me?
> > > Excuse me for my poor english
> > >
> > > --
> > > Dmitry
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > > _______________________________________________
> > > Dev-cpp-users mailing list
> > > Dev...@li...
> > > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users=
=2E
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>
>
>
> ______________________________________________
> Renovamos el Correo Yahoo!: =A1250 MB GRATIS!
> Nuevos servicios, m=E1s seguridad
> http://correo.yahoo.es
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> ___________________________________________________________________
> The information contained in this message and any attachment may be
> proprietary, confidential, and privileged or subject to the work
> product doctrine and thus protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee or
> agent responsible for delivering this message to the intended
> recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this communication in error, please notify me
> immediately by replying to this message and deleting it and all
> copies and backups thereof. Thank you.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Produc
|
