From: Peter C. <new...@gm...> - 2008-10-29 13:14:08
|
Hi all, I had a library that only has gnu version but I do have to use it in my Visual Studio project. So I tried to create a DLL with mingw and I found this post here : How can an MSVC program call an MinGW DLL, and vice versa? http://www.geocities.com/yongweiwu/dllfaq.htm BUT, the example only works for command line! When I create a win32 console project in VS 2008, there is an building error: Error 1 error LNK2019: unresolved external symbol "int __cdecl add(int,int)" (?add@@YAHHH@Z) referenced in function _wmain foo.obj foo The link command is like this: /OUT:"G:\Code\asn1\foo\Debug\foo.exe" /INCREMENTAL /NOLOGO /LIBPATH:"G:\Code\asn1\foo\foodll\Lib" /LIBPATH:"G:\Code\asn1\foo\test" /MANIFEST /MANIFESTFILE:"Debug\foo.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"G:\Code\asn1\foo\Debug\foo.pdb" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT testdll.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib testdll.lib is the lib file I created following the post. I didn't see any difference between the above command generated by VS 2008 and the simple version in the post: cl testmain.c testdll.lib Ah, what's the problem? Anyone could help me? |
From: Marc V. <vai...@fa...> - 2008-10-29 13:53:27
|
On Wed, Oct 29, 2008 at 09:14:02PM +0800, Peter Cai wrote: > Hi all, > > I had a library that only has gnu version but I do have to use it in > my Visual Studio project. > > So I tried to create a DLL with mingw and I found this post here : > > How can an MSVC program call an MinGW DLL, and vice versa? > > http://www.geocities.com/yongweiwu/dllfaq.htm > > > > BUT, the example only works for command line! > > When I create a win32 console project in VS 2008, there is an building error: > > > Error 1 error LNK2019: unresolved external symbol "int > __cdecl add(int,int)" (?add@@YAHHH@Z) referenced in function > _wmain foo.obj foo It looks like your client program foo is c++ so it's expecting c++ name mangling when trying to link to the add function in your dll. Try putting extern "C" before your declaration of add in testdll.h. Also, keep in mind that if you are going to be building c++ DLLs to work across compilers, you need to follow http://www.geocities.com/yongweiwu/dllfaq.htm for your interfaces. Marc |
From: Greg C. <gch...@sb...> - 2008-10-29 14:04:17
|
On 2008-10-29 13:53Z, Marc Vaillant wrote: > > Also, keep in mind that if you are going to be building c++ DLLs to work > across compilers, you need to follow > http://www.geocities.com/yongweiwu/dllfaq.htm > for your interfaces. I think you meant http://aegisknight.org/cppinterface.html |
From: Vincent T. <vt...@un...> - 2008-10-29 15:26:17
|
Hey, >> Also, keep in mind that if you are going to be building c++ DLLs to work >> across compilers, you need to follow >> http://www.geocities.com/yongweiwu/dllfaq.htm >> for your interfaces. > > I think you meant > http://aegisknight.org/cppinterface.html As you guys seems to know what to do exactly about _declspec(dllimport/export), here is what I do in my libraries: In Lib1 main header file, I define: #ifdef EAPI # undef EAPI #endif /* EAPI */ #ifdef _WIN32 # ifdef EFL_LIB1_BUILD # ifdef DLL_EXPORT # define EAPI __declspec(dllexport) # else # define EAPI # endif /* ! DLL_EXPORT */ # else # define EAPI __declspec(dllimport) # endif /* ! EFL_EVIL_BUILD */ #endif /* _WIN32 */ EFL_LIB1_BUILD is defined only if Lib1 is built, which means that: 1) if I build Lib1: a) if i build the DLL, EAPI is defined to __declspec(dllexport) a) If I build the static lib, EAPI is defined to nothing. 2) if I do not build Lib1, EAPI is defined to __declspec(dllimport) Note that, as Lib1 is autotooled, libtool defined DLL_EXPORT when building the DLL Hence, if in Lib2, I include that main header file of Lib1, all the declaration of Lib1 functions will have __declspec(dllimport) is it correct ? thank you Vincent Torri |
From: Роман Д. <DXD...@ya...> - 2008-10-29 17:22:43
|
> 1) if I build Lib1: > a) if i build the DLL, EAPI is defined to __declspec(dllexport) > a) If I build the static lib, EAPI is defined to nothing. > 2) if I do not build Lib1, EAPI is defined to __declspec(dllimport) > Hence, if in Lib2, I include that main header file of Lib1, all the > declaration of Lib1 functions will have __declspec(dllimport) > > is it correct ? If Lib1 is built as a static library, then probably not. Roman. |
From: Vincent T. <vt...@un...> - 2008-10-29 17:29:55
|
On Wed, 29 Oct 2008, wrote: >> 1) if I build Lib1: >> a) if i build the DLL, EAPI is defined to __declspec(dllexport) >> a) If I build the static lib, EAPI is defined to nothing. >> 2) if I do not build Lib1, EAPI is defined to __declspec(dllimport) > >> Hence, if in Lib2, I include that main header file of Lib1, all the >> declaration of Lib1 functions will have __declspec(dllimport) >> >> is it correct ? > > If Lib1 is built as a static library, then probably not. and what should I do, then ? Vincent Torri |
From: Greg C. <gch...@sb...> - 2008-10-29 17:47:24
|
On 2008-10-29 17:29Z, Vincent Torri wrote: > > On Wed, 29 Oct 2008, wrote: > >>> 1) if I build Lib1: >>> a) if i build the DLL, EAPI is defined to __declspec(dllexport) >>> a) If I build the static lib, EAPI is defined to nothing. >>> 2) if I do not build Lib1, EAPI is defined to __declspec(dllimport) >> >>> Hence, if in Lib2, I include that main header file of Lib1, all the >>> declaration of Lib1 functions will have __declspec(dllimport) >>> >>> is it correct ? >> >> If Lib1 is built as a static library, then probably not. > > and what should I do, then ? Use a more complex conditional that defines your API macro to be empty when you're building or using a static library. Here's mine: http://cvs.savannah.gnu.org/viewvc/lmi/lmi/so_attributes.hpp?view=annotate Or just don't ever use any dll attribute, and always link dlls directly. |
From: Vincent T. <vt...@un...> - 2008-10-30 07:21:30
|
On Wed, 29 Oct 2008, Greg Chicares wrote: > On 2008-10-29 17:29Z, Vincent Torri wrote: >> >> On Wed, 29 Oct 2008, wrote: >> >>>> 1) if I build Lib1: >>>> a) if i build the DLL, EAPI is defined to __declspec(dllexport) >>>> a) If I build the static lib, EAPI is defined to nothing. >>>> 2) if I do not build Lib1, EAPI is defined to __declspec(dllimport) >>> >>>> Hence, if in Lib2, I include that main header file of Lib1, all the >>>> declaration of Lib1 functions will have __declspec(dllimport) >>>> >>>> is it correct ? >>> >>> If Lib1 is built as a static library, then probably not. >> >> and what should I do, then ? > > Use a more complex conditional that defines your API macro > to be empty when you're building or using a static library. > Here's mine: > > http://cvs.savannah.gnu.org/viewvc/lmi/lmi/so_attributes.hpp?view=annotate > > Or just don't ever use any dll attribute, and always link > dlls directly. so doing something like that: 1) if I build Lib1: a) if i build the DLL, EAPI is defined to __declspec(dllexport) b) if I build the static lib, EAPI is defined to nothing. 2) if I do not build Lib1 (i'm currently building another lib, say, Lib2): a) if I build the DLL of Lib2, EAPI is defined to __declspec(dllimport) b) if I build the static lib of Lib2, EAPI is defined to nothing. that is: #ifdef _WIN32 # ifdef EFL_EVIL_BUILD # ifdef DLL_EXPORT # define EAPI __declspec(dllexport) # else # define EAPI # endif /* ! DLL_EXPORT */ # else # ifdef DLL_EXPORT # define EAPI __declspec(dllimport) # else # define EAPI # endif /* ! DLL_EXPORT */ # endif /* ! EFL_EVIL_BUILD */ #endif /* _WIN32 */ ? if so, it can be factorized to: #ifdef _WIN32 # ifdef DLL_EXPORT # ifdef EFL_EVIL_BUILD # define EAPI __declspec(dllexport) # else # define EAPI __declspec(dllimport) # endif # else # #define EAPI # endif #endif ? Vincent Torri |
From: Marc V. <vai...@fa...> - 2008-10-29 14:37:32
|
On Wed, Oct 29, 2008 at 02:04:12PM +0000, Greg Chicares wrote: > On 2008-10-29 13:53Z, Marc Vaillant wrote: > > > > Also, keep in mind that if you are going to be building c++ DLLs to work > > across compilers, you need to follow > > http://www.geocities.com/yongweiwu/dllfaq.htm > > for your interfaces. > > I think you meant > http://aegisknight.org/cppinterface.html Yes, thank you. Marc |
From: Peter C. <new...@gm...> - 2008-10-29 15:20:24
|
Hi, thanks for your help! It works! On Wed, Oct 29, 2008 at 10:37 PM, Marc Vaillant <vai...@fa...> wrote: > On Wed, Oct 29, 2008 at 02:04:12PM +0000, Greg Chicares wrote: >> On 2008-10-29 13:53Z, Marc Vaillant wrote: >> > >> > Also, keep in mind that if you are going to be building c++ DLLs to work >> > across compilers, you need to follow >> > http://www.geocities.com/yongweiwu/dllfaq.htm >> > for your interfaces. >> >> I think you meant >> http://aegisknight.org/cppinterface.html > > Yes, thank you. > > Marc > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- 有一种人,不知道是因为DNA的变异还是前世的夙缘,总是无法安稳下来。他们的生命之流如同咆哮奔涌的大河,没有一刻能够停顿下来。在寂静无人的深夜里,无梦相扰的安睡中,心中也有猛兽会随时醒来,躁动不安,永无宁日。 |
From: Peter C. <new...@gm...> - 2008-10-30 04:51:22
|
Oh, I got new problems. Error 3 error LNK2001: unresolved external symbol _Iris_ASN1_buf_offset ir_asn1.obj Vimicro Functions could be found, but how about global variables? _buf_offset is defined as int buf_offset; in the dll's source code. I read the post you recommended, but it doesn't mentions it. :( On Wed, Oct 29, 2008 at 10:37 PM, Marc Vaillant <vai...@fa...> wrote: > On Wed, Oct 29, 2008 at 02:04:12PM +0000, Greg Chicares wrote: >> On 2008-10-29 13:53Z, Marc Vaillant wrote: >> > >> > Also, keep in mind that if you are going to be building c++ DLLs to work >> > across compilers, you need to follow >> > http://www.geocities.com/yongweiwu/dllfaq.htm >> > for your interfaces. >> >> I think you meant >> http://aegisknight.org/cppinterface.html > > Yes, thank you. > > Marc > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- 有一种人,不知道是因为DNA的变异还是前世的夙缘,总是无法安稳下来。他们的生命之流如同咆哮奔涌的大河,没有一刻能够停顿下来。在寂静无人的深夜里,无梦相扰的安睡中,心中也有猛兽会随时醒来,躁动不安,永无宁日。 |
From: Marc V. <vai...@fa...> - 2008-10-30 16:02:22
|
On Thu, Oct 30, 2008 at 12:51:17PM +0800, Peter Cai wrote: > Oh, I got new problems. > > Error 3 error LNK2001: unresolved external symbol > _Iris_ASN1_buf_offset ir_asn1.obj Vimicro > > Functions could be found, but how about global variables? > > _buf_offset is defined as > > int buf_offset; > > in the dll's source code. So it's not exported from your dll? If it's not exported then you can't expect to be able to see the symbol from your client program. You should be using _declspec to export/import the global. Marc |
From: Peter C. <new...@gm...> - 2008-10-31 02:16:49
|
But, By default, all variable and functions will be exported if you don't add any export instructions. I've checked that by dumpbin, you can see that the variable is there. But don't know why msvc is looking for "_buf_offset" not "buf_offset". ====================================================== G:\Code\SDK\IrisASN1\Release>dumpbin /exports IrisASN1.dll Microsoft (R) COFF/PE Dumper Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file IrisASN1.dll File Type: DLL Section contains the following exports for IrisASN1.dll 00000000 characteristics 49097552 time date stamp Thu Oct 30 16:50:26 2008 0.00 version 1 ordinal base 182 number of functions 182 number of names ordinal hint RVA name 1 0 000092F3 ASN_DEBUG_f ...... 40 27 0001C0B0 buf_offset ...... Summary 1000 .bss 3000 .data 2000 .edata 1000 .idata 3000 .rdata 1000 .reloc 15000 .text On Fri, Oct 31, 2008 at 12:02 AM, Marc Vaillant <vai...@fa...> wrote: > On Thu, Oct 30, 2008 at 12:51:17PM +0800, Peter Cai wrote: >> Oh, I got new problems. >> >> Error 3 error LNK2001: unresolved external symbol >> _Iris_ASN1_buf_offset ir_asn1.obj Vimicro >> >> Functions could be found, but how about global variables? >> >> _buf_offset is defined as >> >> int buf_offset; >> >> in the dll's source code. > > So it's not exported from your dll? If it's not exported then you can't > expect to be able to see the symbol from your client program. You should be > using _declspec to export/import the global. > > Marc > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > ====================================================== -- 有一种人,不知道是因为DNA的变异还是前世的夙缘,总是无法安稳下来。他们的生命之流如同咆哮奔涌的大河,没有一刻能够停顿下来。在寂静无人的深夜里,无梦相扰的安睡中,心中也有猛兽会随时醒来,躁动不安,永无宁日。 |