This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Windows support in GDB


Christopher Faylor wrote:

3) Paths. This is a HUGE problem because you can't assume that your Windows customers are interested in using a Unix style of work flow. MinGW supports regular Windows paths without the whole /cygdrive/ system. If you have a pure Windows app interacting with Cygwin tools (take Eclipse for example) you wind up putting an awful lot of cruft in to deal with pathname conversion. You can even get problems when your debug information in your binary has either Cygwin or Windows paths.



Again, AFAIK, gdb works with native paths. If it doesn't then getting it to work with windows paths seems like a lot less pain that getting it to be 100% functional in native windows.


Sometimes yes, sometimes no. It isn't just an issue of gdb not working with native paths because, as you say, it _usually_ does. It's a question of consistency. If the rest of your toolchain is built with MinGW, it makes sense to build everything that way. At the moment, since we're having trouble with gdb on MinGW, we're actually considering what you said, making gdb the exception and just shipping it with a cygwin1.dll until we can get all the kinks ironed out. Another potential gotcha is that it may not work when run under the MinGW environment (as from a bash shell). I haven't checked this for sure but I understand there can be conflicts between msys and cygwin.


One other thing I forgot to mention is memory allocation. Cygwin refuses to allocate the maximum memory available so extremely large projects sometimes have trouble, particularily at the link stage. This isn't a problem on MinGW.

cheers,

Kris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]