From: James M. D. <mdu...@ya...> - 2002-08-26 00:30:23
|
Dear Lists, Please Excuse the longwinded cross posting, I don't know the best place to post this one, so here is the shotgun effect. I really like the great work that has been done on the mingw under debian, finally a great way to write windows programs, not in windows. Hopefully we can get all the cool gnome apps running under windows (or even under using SDL for graphics for that matter (think GNOME SDL! (Cool :) ))). For the Funky DIA diagramming editor that i would like to get running under windows, i need libiconv/gettext/glib/gtk/libxml2/pango and others I dont know yet. I have heard that tor l. has all of of this compiling for mingw32. I have been trying to follow in the footsteps of tor and hand in porting glibc 2.0.4 to mingw32 cross compiler on debian 3.0 + unstable packages. I have gotten libiconv and gettext ported with the help of many nice people on the irc.openprojects.net/#sdl (ali-g, Diablo, LIM (sorry I cannot spell) ) . First I recompiled ported them on mingw32, the ported over. Testing under wine and win3k is running fine. http://LibSDL.org has a well supported toolchain for win32 cross compilation. I wonder if anyone has ported this before? I think tor has done all of this... In anycase I have been following the well written instructions hans and tor on the glib win32 readme. I had to modify the configure and tell it it is not in a cross compiler around line 10000, it wanted to check function prototypes, so I let it use wine to do that. I dont know if I should use the makefile or the makefile.ming, if i need to run libtoolize and automake on gettext and libiconv/libcharset. Hopefully I dont need to do that. The problem is with the resource compiler : gmodule-win32res.lo and gobject-win32res.lo are dependant on the command : ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo which complains that : Using zero as build number Worse, the windres program is not found, but it can be configured in, I took mine from the same place as the compiler : The /usr/local/cross-tools/bin/i386-mingw32msvc-windres is not producing proper object files, but I think it is the right one to use. here is an example build : /bin/sh ../libtool --mode=link gcc -mpentium -fnative-struct --verbose -g -O2 -fnative-struct -Wall -D_REENTRANT -L/home/mdupont/introspector/dia/prefix/libiconv/lib -L/home/mdupont/introspector/dia/prefix/gettext/lib --verbose -o libgmodule-2.0.la -rpath /home/mdupont/introspector/dia/prefix/glib/lib -Wl,--export-dynamic -version-info 0:4:0 -export-dynamic -no-undefined -export-symbols gmodule.def gmodule.lo gmodule-win32res.lo ../glib/libglib-2.0.la -liconv -lintl -liconv # Here is the link command that needs the windres gcc -mpentium -fnative-struct --verbose -Wl,--base-file,.libs/libgmodule-2.0-0.dll-base -Wl,-e,_DllMainCRTStartup@12 -o .libs/libgmodule-2.0-0.dll gmodule.lo gmodule-win32res.lo -L/home/mdupont/introspector/dia/prefix/libiconv/lib -L/home/mdupont/introspector/dia/prefix/gettext/lib -Wl,--export-dynamic it tell mes : Reading specs from /usr/local/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.3-6/specs gcc version 2.95.3-6 (mingw special) here is the full link command : /usr/local/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.3-6/../../../../i386-mingw32msvc/bin/ld -Bdynamic -o .libs/libgmodule-2.0-0.dll /usr/local/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.3-6/../../../../i386-mingw32msvc/lib/crt2.o -L/home/mdupont/introspector/dia/prefix/libiconv/lib -L/home/mdupont/introspector/dia/prefix/gettext/lib -L/usr/local/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.3-6 -L/usr/local/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.3-6/../../../../i386-mingw32msvc/lib --base-file .libs/libgmodule-2.0-0.dll-base -e _DllMainCRTStartup@12 gmodule.lo gmodule-win32res.lo --export-dynamic -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt And then the error : gmodule-win32res.lo: file not recognized: File format not recognized Well that pretty much describes my problem, I hope to hear from anyone that I am doing it much to compilcated and can do it much easier some other way. Best regards and keep up the good work. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Tor L. <tm...@ik...> - 2002-08-26 19:14:28
|
James Michael DuPont writes: > Hopefully we can get all the cool gnome apps running under windows Correct me if I am wrong, but doesn't it go like this: GNOME is intended to provide on Unix some of the (high-level) features in Windows, that on Windows are implemented with stuff like COM and OLE (I am really not an expert in this issues, so bear with me if I babble). It does this using CORBA at the low level. Why would one then need to port GNOME as such to Windows? It wouldn't interoperate with native Windows applications anyway, i.e. you could not include some object that interfaces through COM/OLE/whatever in a GNOME container that uses CORBA, or vice versa. Or is it just eye candy you are after ;-) > The problem is with the resource compiler : > gmodule-win32res.lo and > gobject-win32res.lo are dependant on the command : > ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo > which complains that : > Using zero as build number That is just an informational message, not a warning or error. > gmodule-win32res.lo: file not recognized: File format not recognized The .lo file that the lt-compile-resource script produces is a "libtool object file", which actually is a small text file that contains some assignment lines. (Read lt-compile-resource, it's a relatively simple shell script.) At least .lo files are small text files on my setup (on Windows, not cross-compilation). Maybe with cross-compilation from Unix, .lo files are actually symbolic links to the real .o files? Or just .o files with another name? If so, you need to modify the lt-compile-resource script to just do a symlink or rename instead of creating the small text file. Or you can drop the resource file stuff from the makefiles, it's not essential for the DLLs. Why is this resource crap needed at all, you might ask? I want to include version resources in the GLib etc DLLs. (I.e. what you see in Explorer if you right-click a DLL and select Properties:Version.) It's just a hack that has evolved over time. Without feedback, I haven't bothered to try to improve it. As the compile-resource script says: # This is just my (tm...@ik...) idea, if somebody comes up with a # better way to generate version number resources, don't hesitate to # suggest. Please do try. The essential feature the (lt-)compile-resource script provides to me is that after a "make clean", the resource file gets recompiled with a bumped build number. (This happens only if the build number "stamp" file is present, which it is supposed to be only on the "official packager's" machine, so that new releases of "official" DLLs can be recognized from increasing version number resources. Of course, "official" is a silly word to use without offices or officers.) --tml |
From: Al S. <al...@al...> - 2002-08-26 21:05:35
|
> GNOME is intended to provide on Unix some of the (high-level) features > in Windows, that on Windows are implemented with stuff like COM and > OLE (I am really not an expert in this issues, so bear with me if I > babble). It does this using CORBA at the low level. > > Why would one then need to port GNOME as such to Windows? It wouldn't > interoperate with native Windows applications anyway, i.e. you could > not include some object that interfaces through COM/OLE/whatever in a > GNOME container that uses CORBA, or vice versa. > > Or is it just eye candy you are after ;-) GNOME is also a desktop operating environment supported by an applications framework API. I guess the objective would be to have source-level applications compatibility between the platforms. Not sure I like the idea though. |
From: James M. D. <mdu...@ya...> - 2002-08-26 23:42:45
|
--- Tor Lillqvist <tm...@ik...> wrote: > James Michael DuPont writes: > > Hopefully we can get all the cool gnome apps running under windows > > Correct me if I am wrong, but doesn't it go like this: > > GNOME is intended to provide on Unix some of the (high-level) > features > in Windows, that on Windows are implemented with stuff like COM and > OLE (I am really not an expert in this issues, so bear with me if I > babble). It does this using CORBA at the low level. The Dia and GNOME projects will benefit from the porting of the corba to windows as done by steven obrien via cygwin. http://homepage.ntlworld.com/steven.obrien2/ The usage of the GNOME orbit corba bindings from perl will be a great benefit, I believe GNUMERIC Supports is as well. > Why would one then need to port GNOME as such to Windows? It wouldn't > interoperate with native Windows applications anyway, i.e. you could > not include some object that interfaces through COM/OLE/whatever in a > GNOME container that uses CORBA, or vice versa. I mean gnome apps, like GNUMERIC, ABI WORD, DIA. > Or is it just eye candy you are after ;-) I am after using the DIA toolkit as a scriptable, browser enabled, graphing layout tool. Also under windows, but more importantly under linux. I only got involved in the port to windows when I wanted to try the python bindings with python 2.2 and noticed that I was in DLL HELL. After writing to hans and dia for help, i decided to follow the instructions and compile, but wanted to do so under cygwin, because most of the gnome libs was ported to windows by steven o'brien. This is when I noticed that it was a pain to get all the sources together. As a service to the community I want to help fix the areas that we all can use. > > The problem is with the resource compiler : > > gmodule-win32res.lo and > > gobject-win32res.lo are dependant on the command : > > ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo > > which complains that : > > Using zero as build number > > That is just an informational message, not a warning or error. > > > gmodule-win32res.lo: file not recognized: File format not > recognized > > The .lo file that the lt-compile-resource script produces is a > "libtool object file", which actually is a small text file that > contains some assignment lines. (Read lt-compile-resource, it's a > relatively simple shell script.) Yes this is the version information for the dlls, I will drop it for now. > > At least .lo files are small text files on my setup (on Windows, not > cross-compilation). Maybe with cross-compilation from Unix, .lo files > are actually symbolic links to the real .o files? Or just .o files > with another name? If so, you need to modify the lt-compile-resource > script to just do a symlink or rename instead of creating the small > text file. Or you can drop the resource file stuff from the > makefiles, > it's not essential for the DLLs. > > Why is this resource crap needed at all, you might ask? I want to > include version resources in the GLib etc DLLs. (I.e. what you see in > Explorer if you right-click a DLL and select Properties:Version.) > > It's just a hack that has evolved over time. Without feedback, I > haven't bothered to try to improve it. As the compile-resource script > says: > > # This is just my (tm...@ik...) idea, if somebody comes up with a > # better way to generate version number resources, don't hesitate to > # suggest. > > Please do try. The essential feature the (lt-)compile-resource script > provides to me is that after a "make clean", the resource file gets > recompiled with a bumped build number. (This happens only if the > build > number "stamp" file is present, which it is supposed to be only on > the > "official packager's" machine, so that new releases of "official" > DLLs > can be recognized from increasing version number resources. Of > course, > "official" is a silly word to use without offices or officers.) Thanks for this explaination! Zour help is greatly appreciated! All i need to do now is debug the linker options, it seems like I got all of glib to compile... now I have to get it to link! mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Christof P. <chr...@pe...> - 2002-08-30 14:03:37
|
[Summary: Cygwin is good to compile programs on win32 with minimal porting effort, but a stable port should use MinGW] James Michael DuPont schrieb: > I am after using the DIA toolkit as a scriptable, browser enabled, > graphing layout tool. Also under windows, but more importantly under > linux. > > I only got involved in the port to windows when I wanted to try the > python bindings with python 2.2 and noticed that I was in DLL HELL. > > After writing to hans and dia for help, i decided to follow the > instructions and compile, but wanted to do so under cygwin, because > most of the gnome libs was ported to windows by steven o'brien. Hi James, To introduce me: I ported magus [ http://midgard.berlios.de ] (a gtk[mm] application) to Windows, so I think I know a bit about the subject. (Also I'm maintainer of glademm, so I'm familiar to the gnome project) I really recommend against a cygwin environment for 'native' Windows programs intended for a broader audience ... ... because no ordinary Windows user will ever enjoy unix-style file names for loading and saving his/her documents. [We even switched to the native 'Explorer' for file selection after a bit of discussion] ... because X11 clients feel alien to Windows users at best In short: Most Windows users do not like a POSIX environment, which is what cygwin is supposed to provide. That's why we decided to bite the bullet and switch to MinGW/MSys & Tor's gtk dlls. And it's really not trivial to tell cygwin to generate pure (aka non-cygwin) win32 binaries/dlls (I failed a couple of times, but remember that was one year ago, the environment should have improved). Apart from that I'm not aware of any working cygwin gtk dlls (apart from the X11 based ones). I also tried one year ago and failed ... I wish you all the best for porting dia to windows! But I simply don't think that this way (using cygwin) would get you there. Feel free to ask me any questions about the Gtk/MinGW/MSys combination. Christof PS: I also learned that most Windows users prefer an exe (made by an installer) over a zip. I'd recommend inno setup. |
From: Michael T. <to...@cs...> - 2002-08-30 14:19:26
|
i believe DIA has already been ported to windows, at least an older version of DIA. http://hans.breuer.org/dia/ Michael On Fri, 2002-08-30 at 08:03, Christof Petig wrote: > [Summary: Cygwin is good to compile programs on win32 with minimal > porting effort, but a stable port should use MinGW] > > James Michael DuPont schrieb: > > I am after using the DIA toolkit as a scriptable, browser enabled, > > graphing layout tool. Also under windows, but more importantly under > > linux. > > > > I only got involved in the port to windows when I wanted to try the > > python bindings with python 2.2 and noticed that I was in DLL HELL. > > > > After writing to hans and dia for help, i decided to follow the > > instructions and compile, but wanted to do so under cygwin, because > > most of the gnome libs was ported to windows by steven o'brien. > > Hi James, > > To introduce me: > I ported magus [ http://midgard.berlios.de ] (a gtk[mm] application) to > Windows, so I think I know a bit about the subject. (Also I'm maintainer > of glademm, so I'm familiar to the gnome project) > > I really recommend against a cygwin environment for 'native' Windows > programs intended for a broader audience ... > > ... because no ordinary Windows user will ever enjoy unix-style file > names for loading and saving his/her documents. [We even switched to the > native 'Explorer' for file selection after a bit of discussion] > ... because X11 clients feel alien to Windows users at best > > In short: Most Windows users do not like a POSIX environment, which is > what cygwin is supposed to provide. > > That's why we decided to bite the bullet and switch to MinGW/MSys & > Tor's gtk dlls. And it's really not trivial to tell cygwin to generate > pure (aka non-cygwin) win32 binaries/dlls (I failed a couple of times, > but remember that was one year ago, the environment should have improved). > > Apart from that I'm not aware of any working cygwin gtk dlls (apart from > the X11 based ones). I also tried one year ago and failed ... > > I wish you all the best for porting dia to windows! But I simply don't > think that this way (using cygwin) would get you there. > > Feel free to ask me any questions about the Gtk/MinGW/MSys combination. > Christof > > PS: I also learned that most Windows users prefer an exe (made by an > installer) over a zip. I'd recommend inno setup. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users -- Public key available from http://students.cs.byu.edu/~torriem |
From: James M. D. <mdu...@ya...> - 2002-08-30 14:37:09
|
--- Michael Torrie <to...@cs...> wrote: > i believe DIA has already been ported to windows, at least an older > version of DIA. > > http://hans.breuer.org/dia/ I know about the dia port : if you read the page from him, he has taken down the binary distribution after I pointed out that he might be in violation of the GPL. Therefore I have declared that I will take over the porting and binary distribution. Originally I was complaining that I had to scrounge around to get all the parts to compile the program. It turns out that the GPL section 3 stipulates that you make all the sources available in the same location as the binaries, and that all non-standard libs are made available. Also this includes all the scripts, the configuration and the settings for the exact version of the source used to compile the binaries. See : http://www.gnu.org/licenses/gpl.html (Or you give a written offer to make them available) This means for anyone who is distributing any binaries or even an installer must be burdened with this extra baggage. The FSF has also been made aware of this practice and have stated that It does indeed look like a (albeit) minor violation. In addition, all of the GNOME project contains parts of the FSF copyright assigned gettext. That makes them a partial copyright holder and they are able to prosecute any violators. My compliation and piecing togeather of the sources will be good for all who want to distribute the binaries, because I will create a full set of compiliable sources and put them in one place on my web server. Also a written offer will be published that can bet put in a CD distribution without the sources. This extra bit of work will make it easier for anyone else to copy it and do the same. I hope that my efforts will restore the importance of source code and freedom of source. If we all live up to the exact sentence of the GPL, then it will become easier and less painfull to port the software to new platforms and compilers (like mingw32 under debian) and also easier to change. Right now I am just configuring and compiling the sources from scratch, most of the porting has been done my Tor and Hans already. I hope that others will find it easy to compile and use the packages that I am building. I hope that you all who are reading this will take the time to review your practices, if you have not already. Best regards, Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: James M. D. <mdu...@ya...> - 2002-08-30 14:21:12
|
Hallo Christof! I am sorry for the confusion, so let me explain : I was originally trying to compile the DIA stuff for cygwin, and have dropped that. In fact, I am not working on it under windows anymore, but under debian with ming32 and wine for testing. --- Christof Petig <chr...@pe...> wrote: > [Summary: Cygwin is good to compile programs on win32 with minimal > porting effort, but a stable port should use MinGW] Yes I aggree. > To introduce me: > I ported magus [ http://midgard.berlios.de ] (a gtk[mm] application) > to > Windows, so I think I know a bit about the subject. (Also I'm > maintainer > of glademm, so I'm familiar to the gnome project) Cool! > > I really recommend against a cygwin environment for 'native' Windows > programs intended for a broader audience ... Yes, I have made the switch a week ago. Now I am compiling under Mingw32. As a status note : I just completed all the glib dlls, and am now working on GTK!!! Christof, I hope to be looking at some of file handling issues, but right now it is just configuring, compiling and linking that takes up the most time. Thanks for you tips and hope to hear from you again, Ein Schönes Wochenende wünche ich Dir! mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Christopher F. <cg...@re...> - 2002-08-30 17:32:28
|
On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: >[Summary: Cygwin is good to compile programs on win32 with minimal >porting effort, but a stable port should use MinGW] Summary: If you want to ignore all of the work that has gone into -mno-cygwin to make it work reliably, then use MinGW. cgf |
From: James M. D. <mdu...@ya...> - 2002-08-30 20:34:59
|
--- Christopher Faylor <cg...@re...> wrote: > On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: > >[Summary: Cygwin is good to compile programs on win32 with minimal > >porting effort, but a stable port should use MinGW] > > Summary: If you want to ignore all of the work that has gone into > -mno-cygwin to make it work reliably, then use MinGW. I have a great deal of respect for cygwin, and use it every day at work. The amount of packages for it great. For me, the only reason why I am using mingw, is because it is hosted under linux. Like many of you, I dont have windows at home, and would never fork out the cash for a legal copy of the MSVC compilier. That is why I am so excited that the mingw is coming along nicely. I hope to find portability throught all the incarnations of the gcc toolchain. It is interesting how autoconf, automake, m4 and perl play such a large role in the build process. I long to convert all of this into some perl runtime, at least something that can be debugged. m4 to perl translator? introspector::m4, inline::m4? hmmm, have to look into the implementation. At least the .configure script should be a debuggable object. Perl would fit in somehow. mike Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Christopher F. <cg...@re...> - 2002-08-30 21:10:13
|
On Fri, Aug 30, 2002 at 01:34:58PM -0700, James Michael DuPont wrote: > >--- Christopher Faylor <cg...@re...> wrote: >> On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: >> >[Summary: Cygwin is good to compile programs on win32 with minimal >> >porting effort, but a stable port should use MinGW] >> >> Summary: If you want to ignore all of the work that has gone into >> -mno-cygwin to make it work reliably, then use MinGW. > >I have a great deal of respect for cygwin, and use it every day at >work. The amount of packages for it great. > >For me, the only reason why I am using mingw, is because it is hosted >under linux. Like many of you, I dont have windows at home, and would >never fork out the cash for a legal copy of the MSVC compilier. I don't know what "hosted under Linux" means but there is nothing special about mingw. Both cygwin and mingw can be cross built on linux. Cygwin started its life being built only on UNIX and current releases are all built on linux. I don't mind people being excited about MinGW but it doesn't have to be at the expense of Cygwin. A "stable port" of a windows-only application could easily be maintained with Cygwin's gcc. Implying that cygwin produces unstable code is not necessary. I understand and respect that there are good reasons to use MinGW but promoting urban myths about cygwin is not a good way to promote the project. cgf |
From: James M. D. <mdu...@ya...> - 2002-08-30 23:29:17
|
--- Christopher Faylor <cg...@re...> wrote: > On Fri, Aug 30, 2002 at 01:34:58PM -0700, James Michael DuPont wrote: > > > >--- Christopher Faylor <cg...@re...> wrote: > >> On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: > >> >[Summary: Cygwin is good to compile programs on win32 with > minimal > >> >porting effort, but a stable port should use MinGW] > >> > >> Summary: If you want to ignore all of the work that has gone into > >> -mno-cygwin to make it work reliably, then use MinGW. > > > >I have a great deal of respect for cygwin, and use it every day at > >work. The amount of packages for it great. > > > >For me, the only reason why I am using mingw, is because it is > hosted > >under linux. Like many of you, I dont have windows at home, and > would > >never fork out the cash for a legal copy of the MSVC compilier. > > I don't know what "hosted under Linux" means but there is nothing > special > about mingw. Both cygwin and mingw can be cross built on linux. > Cygwin > started its life being built only on UNIX and current releases are > all > built on linux. There are also cygwin packages for debian. > > I don't mind people being excited about MinGW but it doesn't have to > be > at the expense of Cygwin. A "stable port" of a windows-only > application > could easily be maintained with Cygwin's gcc. Implying that cygwin > produces unstable code is not necessary. Fine,when I get my set of packages ready for compilation by anyone, Then we can use APT to fetch them to cygwin and compile them. The packages have to get cleaned, the documentation and support from the SDL guys is great, debian as well. I would have used cygwin if I had found that first. > > I understand and respect that there are good reasons to use MinGW but > promoting urban myths about cygwin is not a good way to promote the > project. As I said, I use cygwin all the time. When I get stable builds in mingw32 under debian, then I will try them under windows. Then into cygwin. We will meet in the middle. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Christof P. <chr...@pe...> - 2002-09-02 06:58:13
|
I wrote > [Summary: Cygwin is good to compile programs on win32 with minimal > porting effort, but a stable port should use MinGW] replace cygwin by "cygwin's posix runtime environment" and MinGW by "MinGW's or -mno-cygwin's msvcrt environment" and you get what I meant. I never noticed that it was that misleading. Christopher Faylor schrieb: > I don't mind people being excited about MinGW but it doesn't have to be > at the expense of Cygwin. A "stable port" of a windows-only application > could easily be maintained with Cygwin's gcc. Implying that cygwin > produces unstable code is not necessary. Yes, but I don't think that a stable _port_ to Windows should use the cygwin POSIX _runtime_ environment. A port should use -mno-cygwin or MinGW runtime environment. Do we agree on that point? > I understand and respect that there are good reasons to use MinGW but > promoting urban myths about cygwin is not a good way to promote the > project. Sorry. I never said that cygwin's gcc is incapable of producing correct code (if used properly). But as a separate point: One year ago I made such bad experience with -mno-cygwin that I never even considered using it again [I need C++ and libtool]. (See separate mail) Christof |
From: Christof P. <chr...@pe...> - 2002-09-02 06:45:23
|
Christopher Faylor schrieb: > On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: > >>[Summary: Cygwin is good to compile programs on win32 with minimal >>porting effort, but a stable port should use MinGW] I meant build target not compiler tool chain. > Summary: If you want to ignore all of the work that has gone into > -mno-cygwin to make it work reliably, then use MinGW. That was not what I said. I said nothing about the cygwin toolchain but about the build target. Last year the -mno-cygwin (I need C++ & libtool !!!) support was suited to give me a lots of headaches and made me angry to have even tried. I never got a reliable gtkmm.dll out of that! And I tried for weeks. From my experience and reading on the MinGW list: - there seemed to be no one at cygwin interested in reliably maintaining the no-cygwin part. - Mixing header files and import libraries was easily done within cygwin. The result normally failed to link or crashed randomly - C++ support for -mno-cygwin was severely damaged And I was not aware that it improved _that_ much. I still can't believe that the cygwin toolchain will give you a -mno-cygwin environment without lots of (undocumented?) 'never do this' and 'do it this way'. Sorry, too much negative personal experience with cygwin on my side Christof |
From: Christopher F. <cg...@re...> - 2002-09-02 15:46:21
|
On Mon, Sep 02, 2002 at 08:45:14AM +0200, Christof Petig wrote: >Christopher Faylor schrieb: >>On Fri, Aug 30, 2002 at 04:03:28PM +0200, Christof Petig wrote: >> >>>[Summary: Cygwin is good to compile programs on win32 with minimal >>>porting effort, but a stable port should use MinGW] > >I meant build target not compiler tool chain. > >>Summary: If you want to ignore all of the work that has gone into >>-mno-cygwin to make it work reliably, then use MinGW. > >That was not what I said. I said nothing about the cygwin toolchain but >about the build target. > >Last year the -mno-cygwin (I need C++ & libtool !!!) support was suited >to give me a lots of headaches and made me angry to have even tried. I >never got a reliable gtkmm.dll out of that! And I tried for weeks. > >From my experience and reading on the MinGW list: >- there seemed to be no one at cygwin interested in reliably maintaining >the no-cygwin part. I have always "reliably maintained" as much of the -mno-cygwin mechanism as was available. Others had volunteered to maintain the c++ part of -mno-cygwin but they never followed through on their promises. >- Mixing header files and import libraries was easily done within >cygwin. The result normally failed to link or crashed randomly Yes, if you include -I/usr/include to get the cygwin libraries then it is pretty easily done. You'd have to wonder why someone would do that but... The same thing holds for libraries. If you try to use a cygwin library with -mno-cygwin then the linker will oblige. Maybe this is one of the undocumented issues that so discouraged you but it seems rather like common sense to me. So, I guess you really are right. -mno-cygwin doesn't protect users against themselves enough. Perhaps this is a valid criticism of -mno-cygwin. However, I personally, have to wonder about the thinking process of someone who uses -mno-cygwin, notices that there are such things as /usr/include/mingw and /usr/lib/mingw where mingw-specific files reside but nevertheless include -lblah on the command line when they notice that, say, fork() is missing from their mingw program. In the case of c++ it was a real lack and could cause confusion. I just checked the FAQ and can't believe that it wasn't documented as not working. I should have suggested that years ago. >- C++ support for -mno-cygwin was severely damaged > >And I was not aware that it improved _that_ much. It has. As I have previously said in the mingw mailing list, the test versions of gcc that are now available for cygwin should provide full-featured mingw support. >I still can't believe that the cygwin toolchain will give you a >-mno-cygwin environment without lots of (undocumented?) 'never do this' >and 'do it this way'. Well, belief is a funny thing. And, documentation is as good as the volunteers who are willing to spend time improving it. I suppose that you ran against a previous limitation and it didn't occur to you to improve the process by offering a documentation patch. That's your right, of course. I was working under the misapprehension that the c++/-mno-cygwin problem was documented but apparently I was wrong. Anyway, I've gone to some considerable effort to improve -mno-cygwin. No reason for you to believe me but there's also no reason for you to continue to misrepresent the state of -mno-cygwin since things have changed and your information is now obsolete. >Sorry, too much negative personal experience with cygwin on my side cgf |
From: Earnie B. <ear...@ya...> - 2002-09-02 19:16:58
|
Christopher Faylor wrote: > Anyway, I've gone to some considerable effort to improve -mno-cygwin. > No reason for you to believe me but there's also no reason for you to > continue to misrepresent the state of -mno-cygwin since things have > changed and your information is now obsolete. > > >Sorry, too much negative personal experience with cygwin on my side Can this discussion about -mno-cygwin be moved to the Cygwin list? FWIW, MinGW doesn't support -mno-cygwin. Thanks, Earnie. |
From: Christopher F. <cg...@re...> - 2002-09-03 01:13:00
|
On Mon, Sep 02, 2002 at 03:17:37PM -0400, Earnie Boyd wrote: >Christopher Faylor wrote: >>Anyway, I've gone to some considerable effort to improve -mno-cygwin. >>No reason for you to believe me but there's also no reason for you to >>continue to misrepresent the state of -mno-cygwin since things have >>changed and your information is now obsolete. >> >>>Sorry, too much negative personal experience with cygwin on my side > >Can this discussion about -mno-cygwin be moved to the Cygwin list? >FWIW, MinGW doesn't support -mno-cygwin. Certainly. Sorry for the noise. cgf |