"Duft Markus" <[EMAIL PROTECTED]> writes: > When building with wgcc there are a few benefits: > > Wgcc uses the native windows compiler to build (so the code may or may > not be faster ;o)) and whats a lot more important: the debug > information produced is readable by visual studio, so you can debug > the output. Gdb on windows (at least on interix) is so terribly > broken, i could not debug 10 lines of code without gdb failing at some > point.
Works great for me under Cygwin, especially through emacs. > The visual studio debugger (the 2005 version especially) is > very very much better. (gdb on cygwin doesn't behave too good > either. What's wrong with it? > With cygwin the thing is, that cygwin isn't really quite stable on win > xp and above when using more than one CPU. Never had a problem there, but haven't stressed Cygwin since I got 2 cores. However, given your claims about Cygwin/gdb I am inclined to wonder about this claim. > The second thing is, that resulting executables depend on msvcrt.lib > and are therefore binary compatible with nearly everything ;o) on > windows. That's also true of MinGW, right? > When using gcc it has it's own libc (on interix gcc is a > interix build, and has really not much to do with windows.... ;o//) > and one can't link those things together, so in gcc built binaries one > can _not_ use the win32 API which, on windows, is not really desireable. Huh? Not so; I have used the win32 API even through cygwin GCC. And then there's gcc -mno-cygwin. > The last thing is, that tools such as Rational Purify may be used to > examine the resulting binaries. It's all just really native ;o) > > I'm really overwhelmed that someone outside my company finally shows > at least _some_ interest. It's really cool, give it a try! Not sure what I'm missing here, but at this point I don't see why I should bother. The existing tools work for me and are well-established, with good support. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
