Ken Takata wrote: > 2018/5/21 Mon 1:30:53 UTC+9 Bram Moolenaar wrote: > > I want to try debugging on MS-Windows with gdb. I normally build with > > MSVC, but I don't see a way to use that executable with gdb (perhaps > > it's possible with some compiler flag?). > > > > So I'll use MinGW for compiling. MinGW provides gcc and make, so I > > expect this to work: > > make -f Make_ming.mak GUI=no DEBUG=yes > > > > This gives an error in diff.c: > > storage size of 'st' isn't known. > > > > Hmm. I can work around it by changing the condition in vim.h: > > > > /* Use 64-bit stat structure if available. */ > > #if (defined(_MSC_VER) && (_MSC_VER >= 1300)) || defined(__MINGW32__) > > # define HAVE_STAT64 > > typedef struct _stat64 stat_T; > > #else > > typedef struct stat stat_T; > > #endif > > > > So use "struct stat". I wonder why this change is needed. perhaps the > > #ifdef is wrong? > > > > Then it compiles many files but fails when building iscygpty.c . > > It complains that _WIN32_WINNT and WINVER differ. That's because the > > build file has: > > > > $(OUTDIR)/iscygpty.o: iscygpty.c $(CUI_INCL) > > $(CC) -c $(CFLAGS) iscygpty.c -o $(OUTDIR)/iscygpty.o -U_WIN32_WINNT > > -D_WIN32_WINNT=0x0600 -DUSE_DYNFILEID -DENABLE_STUB_IMPL > > > > Overruling _WIN32_WINNT for one file seems like a bad idea, why was this > > added? But building iscygpty.c with WINVER set to 0x0501 apparently > > doesn't work. > > > > So instead I specify WINVER to be 0x0600. I wonder how it can ever work > > without that. Perhaps we should make it the default? > > For iscygpty.c, how about adding `-UWINVER -DWINVER=0x0600`? (Not tested.) > iscygpty requires new Win32 APIs which were added in Windows Vista. Does it make sense to require WINVER 0x0600 here while 0x501 is the default above? Doesn't it mean the binary won't work properly on Windows XP anyway? Then we might as well make 0x0600 the default. And add a comment to use 0x0501 for XP, and the need to disable using iscygpty.
> For the other problem, I think your MinGW is too old. (The above problem > should be caused by the same reason, though.) > I highly recommend you to use MinGW-w64 instead of the original MinGW (which > looks dead). I ran the installer to update, but it appears nothing happened. > There are some distributions which provide binary packages of MinGW-w64, > and I think MSYS2 is the best. (https://www.msys2.org/) > > If we still need to support the original MinGW, we might need some > modifications to the codes and makefiles. However, I can't help it, > because I have already uninstalled the original MinGW. I think the main use of MinGW is to build without MSVC. And since it's freely available there shouldn't be much problem getting the latest version. So how about updating the instructions to add a step-by-step explanation how to build Vim with MinGW? Including hints how to get the latest version (and possibly deleting the old one, if that is needed). -- If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be "meetings." /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
