From: Yasir N. K. <kh...@in...> - 2006-11-22 10:24:47
|
Hi, I want to make a dll using gcc on cygwin and use it in an MFC program that i make in MSVC 2005. I have tried a dozen solutions from Internet but none worked. I am able to use this dll in gcc applications and in C programs that i compiled using MSVC compiler (cl), but i am unable to even load the dll in an MFC application. Can anybody provide steps for doing so, as i am not a big expert in dll's. Thanks, Yasir |
From: Brian D. <br...@de...> - 2006-11-22 11:07:19
|
Yasir Niaz Khan wrote: > I want to make a dll using gcc on cygwin and use it in an MFC program > that i make in MSVC 2005. I have tried a dozen solutions from Internet > but none worked. I am able to use this dll in gcc applications and in C > programs that i compiled using MSVC compiler (cl), but i am unable to > even load the dll in an MFC application. Can anybody provide steps for > doing so, as i am not a big expert in dll's. It sounds like you're trying to mix C++ objects from different compilers (or even different branches of g++.) That won't work, because there are a great number of behind the scenes details in C++ that are compiler-implementation-specific. This is why each compiler has its own unique name mangling scheme, to prevent people from succeeding in linking foreign C++ objects. You can get a great deal of interoperability by restricting all interfaces to plain C or C++ with 'extern "C"' semantics but you can't directly mix C++. That's just how it goes. There's a page on this in the wiki. Also, Cygwin is a separate project with its own mailing list; it's not supported here. However, the Cygwin gcc and MinGW gcc are quite similar (and Cygwin's "gcc -mno-cygwin" is a shortcut for running the MinGW gcc binary in the Cygwin build environment.) Brian |
From: Earnie B. <ea...@us...> - 2006-11-22 12:44:15
|
Quoting Brian Dessent <br...@de...>: > (and Cygwin's "gcc -mno-cygwin" is a shortcut for running the MinGW gcc > binary in the Cygwin build environment.) > It has been a few years since I've used Cygwin proper but when I was ``gcc -mno-cygwin'' did execute the MinGW binary it just instructed the linker to use the MinGW supplied MSVCRT.DLL import library. Has that really changed? Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Easy Blogger Creator: <a href="http://give-me-an-offer.com/1006/">Offer 1006</a> 4 Seasons Wine - Buy 6, Get 6 Free <a href="http://give-me-an-offer.com/1007/">Offer 1007</a> |
From: Keith M. <kei...@to...> - 2006-11-22 13:01:43
|
Earnie Boyd wrote, quoting Brian Dessent: >> (and Cygwin's "gcc -mno-cygwin" is a shortcut for running the MinGW >> gcc binary in the Cygwin build environment.) > > It has been a few years since I've used Cygwin proper but when I was > ``gcc -mno-cygwin'' did execute the MinGW binary ... I guess you really mean `... did *not* execute ...'? > it just instructed the > linker to use the MinGW supplied MSVCRT.DLL import library. Has that > really changed? I do occasionally use Cygwin, but prefer a standard MinGW setup, run in MSYS, when building native Win32 apps. Nevertheless, I too would like to see a definitive clarifying statement on this. How, for example, does `-mno-cygwin' provide for avoidance of Cygwin configuration dependencies polluting the test environment of an autoconf generated configure script? Regards, Keith. |
From: Brian D. <br...@de...> - 2006-11-22 13:18:35
|
Keith MARSHALL wrote: > I do occasionally use Cygwin, but prefer a standard MinGW setup, run in > MSYS, when building native Win32 apps. Nevertheless, I too would like > to see a definitive clarifying statement on this. How, for example, does > `-mno-cygwin' provide for avoidance of Cygwin configuration dependencies > polluting the test environment of an autoconf generated configure script? It is essentially identical to a cross compiler (and in fact, I think it is setup so that invoking i686-pc-mingw32-gcc is equivalent to gcc -mno-cygwin.) When we build the Cygwin setup.exe program, which is a native app that doesn't use the Cygwin runtime (for obvious reasons) the recommended configuration is ../configure -C --disable-shared --host=i686-pc-mingw32 \ --build=i686-pc-cygwin CC="gcc -mno-cygwin" \ CXX="g++ -mno-cygwin" Brian |
From: Keith M. <kei...@to...> - 2006-11-22 14:20:49
|
Brian Dessent wrote, quoting me: >> I do occasionally use Cygwin, but prefer a standard MinGW setup, run in >> MSYS, when building native Win32 apps. Nevertheless, I too would like >> to see a definitive clarifying statement on this. How, for example, does >> `-mno-cygwin' provide for avoidance of Cygwin configuration dependencies >> polluting the test environment of an autoconf generated configure script? > > It is essentially identical to a cross compiler (and in fact, I think it > is setup so that invoking i686-pc-mingw32-gcc is equivalent to gcc > -mno-cygwin.) Thanks for this, Brian. If I read that correctly, then `-mno-cygwin' alone isn't sufficient to make configure do the right thing; it would also be necessary to add `host', (and for strict autoconf doc compliance, `build') specifications, as in... > When we build the Cygwin setup.exe program, which is a > native app that doesn't use the Cygwin runtime (for obvious reasons) the > recommended configuration is > > ../configure -C --disable-shared --host=i686-pc-mingw32 \ > --build=i686-pc-cygwin CC="gcc -mno-cygwin" \ > CXX="g++ -mno-cygwin" But this is subtly different from what I would specify for building any cross compiled application, on my GNU/Linux box for example, where path/to/top_srcdir/configure -C --disable-shared --host=i586-mingw32 \ --build=i686-linux does the right thing, *without* the `-mno-cygwin' hackery, to produce a configuration which will ultimately `make' a native MinGW binary. Sorry, I am still somewhat confused; if `-mno-cygwin' is equivalent to `--host=i686-pc-mingw32', why is `-mno-cygwin' needed at all? Regards, Keith. |
From: Brian D. <br...@de...> - 2006-11-22 14:45:07
|
Keith MARSHALL wrote: > > ../configure -C --disable-shared --host=i686-pc-mingw32 \ > > --build=i686-pc-cygwin CC="gcc -mno-cygwin" \ > > CXX="g++ -mno-cygwin" > > But this is subtly different from what I would specify for building any > cross compiled application, on my GNU/Linux box for example, where > > path/to/top_srcdir/configure -C --disable-shared --host=i586-mingw32 \ > --build=i686-linux > > does the right thing, *without* the `-mno-cygwin' hackery, to produce a > configuration which will ultimately `make' a native MinGW binary. > > Sorry, I am still somewhat confused; if `-mno-cygwin' is equivalent to > `--host=i686-pc-mingw32', why is `-mno-cygwin' needed at all? I was wrong, there is no provision for using i686-pc-mingw32-gcc. I want to say that if you created a wrapper script consisting of 'exec gcc -mno-cygwin "$@"' and called it i686-pc-mingw32-gcc (and likewise for g++ et al.) that it would work identically to a cross compiler, but I haven't tried this. I have to say also that I don't know what the typical user of -mno-cygwin does, i.e. I don't know if the "--host=i686-pc-mingw32 CC='gcc -mno-cygwin'" paradigm is widespread or if a lot of people out there just add the flag without telling configure to do a cross compile. That would lead to seriously strange results, like fork() being detected but failing to link, so I can't see it working for any non-trivial package. Or at least maybe it works only in the case of packages that have native Win32 code already and conditionalize it on WIN32 being defined rather than doing configure tests. (And for the record, using Cygwin's gcc, WIN32 is *not* defined, but it is defined when invoked as gcc -mno-cygwin.) I believe that historically there has been a lot of confusion about what exactly -mno-cygwin does, and it seems like I have run into countless posters on the Cygwin list that think using this switch somehow sprinkles magic fairy dust on the situation and erases a runtime dependance on cygwin1.dll without also taking away posix emulation. But I hope nowadays it has been explained there enough times that this switch gives you a MinGW toolchain, i.e. targeting MSVCRT and having no Cygwin emulation bits whatsoever, that people now understand. Brian |
From: Earnie B. <ea...@us...> - 2006-11-22 16:12:57
|
Quoting Brian Dessent <br...@de...>: > > I believe that historically there has been a lot of confusion about what > exactly -mno-cygwin does, and it seems like I have run into countless Check the gcc specs file. You'll find that mno-cygwin is used to tell the compiler the system include path and the linker the system library path and runtime library. At least that is the way it worked when I used it years ago. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Easy Blogger Creator: <a href="http://give-me-an-offer.com/1006/">Offer 1006</a> 4 Seasons Wine - Buy 6, Get 6 Free <a href="http://give-me-an-offer.com/1007/">Offer 1007</a> |
From: Brian D. <br...@de...> - 2006-11-22 16:50:34
|
Earnie Boyd wrote: > Check the gcc specs file. You'll find that mno-cygwin is used to tell > the compiler the system include path and the linker the system library > path and runtime library. At least that is the way it worked when I > used it years ago. Um, please re-read what I wrote. I understand precisely how the switch works. I was trying to explain that I have witnessed many posters over the years on the Cygwin list that seem to misunderstand what it means, which was supposed to address the question of "how do people typically use -mno-cygwin". Brian |
From: Brian D. <br...@de...> - 2006-11-22 13:12:52
|
Earnie Boyd wrote: > > (and Cygwin's "gcc -mno-cygwin" is a shortcut for running the MinGW gcc > > binary in the Cygwin build environment.) > > > > It has been a few years since I've used Cygwin proper but when I was > ``gcc -mno-cygwin'' did execute the MinGW binary it just instructed the > linker to use the MinGW supplied MSVCRT.DLL import library. Has that > really changed? I base this on what Gerrit, the previous Cygwin gcc maintainer, said in the past, e.g. <http://www.cygwin.com/ml/cygwin/2005-05/msg01188.html>. The packaging is split into separate packages, gcc-core and gcc-mingw-core, gcc-g++ and gcc-mingw-g++, with each having separate copies of everything, populating the /usr/gcc/i686-pc-mingw32/ tree. Actually, I just checked again and it looks like the cc1.exe/cc1plus.exe/et al. backends are symlinks, so those are shared between the packages, but everything else (crtbegin, crtend, libg2c, libgcov, libobjc, libgcc, libstdc++, libsupc++, include/c++, adainclude, adalib) is separate and not shared. So I guess it's not true to say that it's executing the same binaries, but the intention is that the toolchain is supposed to emit identical output as the one on mingw.org. Brian |
From: Keith M. <kei...@to...> - 2006-11-22 10:36:05
|
Sorry to be so blunt, but... Yasir Niaz Khan wrote: > I want to make a dll using gcc on cygwin ... So, you want to be asking on a Cygwin list, not here. > and use it in an MFC program that i make in MSVC 2005. And we support *MinGW*; we do not aim to provide a forum for discussion of your MSVC problems -- take them to Microsoft. > I have tried a dozen solutions from Internet > but none worked. I am able to use this dll in gcc applications and in > C programs that i compiled using MSVC compiler (cl), but i am unable > to even load the dll in an MFC application. Can anybody provide steps > for doing so, as i am not a big expert in dll's. And this isn't the place to ask, unless you are using the tools which we provide. Regards, Keith. |