Re: Trying to build with MinGW
Hi, 2020/3/9 Mon 0:02:21 UTC+9 Bram Moolenaar wrote: > > > John Marriott wrote: > > > On 08-Mar-2020 00:39, Bram Moolenaar wrote: > > > On my Windows 10 laptop I'm trying to build a non-GUI debug version > with > > > MinGW. It has a few complaints, first one is that INT_MAX was not > > > defined. I solved that by including in vim.h. > > > > > > Building with the terminal feature fails with > > > LPROC_THREAD_ATTRIBUTE_LIST undefined. > > > > > > I disabled FEAT_TERMINAL for now, then the linking fails with > > > "-municode" not being defined. > > > > > > Is this perhaps because my MinGW version is too old? > > > > > > > > Hi Bram, > > > > Yeah I reckon it's old. I have been using mingw64 to build both vim and > > gvim for years now with no problems. > > > > It could be time to update. > > > > In case you were wondering, I use the latest x64 builds from here > > (currently gcc v9.2.1): https://gcc-mcf.lhmouse.com > > I've also used builds from here: > > https://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64 > > I've not tried it but I think builds from here work as well (gcc v9.1): > > https://nuwen.net/mingw.html > > For an older gcc release: > > > https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh > > > Thanks for the hints. > > I tried the second entry in INSTALLpc.txt, using MSYS2 with MinGW, but > the website appears to be down. > > It would be nice if we have one way that "just works"... > It seems that the msys2 site is down these few days. You can download the installer from here for now: https://sourceforge.net/projects/msys2/files/latest/download Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0a3438f2-fd8d-4c51-986e-f80518d6c864%40googlegroups.com.
Re: Trying to build with MinGW
John Marriott wrote: > On 08-Mar-2020 00:39, Bram Moolenaar wrote: > > On my Windows 10 laptop I'm trying to build a non-GUI debug version with > > MinGW. It has a few complaints, first one is that INT_MAX was not > > defined. I solved that by including in vim.h. > > > > Building with the terminal feature fails with > > LPROC_THREAD_ATTRIBUTE_LIST undefined. > > > > I disabled FEAT_TERMINAL for now, then the linking fails with > > "-municode" not being defined. > > > > Is this perhaps because my MinGW version is too old? > > > > > Hi Bram, > > Yeah I reckon it's old. I have been using mingw64 to build both vim and > gvim for years now with no problems. > > It could be time to update. > > In case you were wondering, I use the latest x64 builds from here > (currently gcc v9.2.1): https://gcc-mcf.lhmouse.com > I've also used builds from here: > https://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64 > I've not tried it but I think builds from here work as well (gcc v9.1): > https://nuwen.net/mingw.html > For an older gcc release: > https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh Thanks for the hints. I tried the second entry in INSTALLpc.txt, using MSYS2 with MinGW, but the website appears to be down. It would be nice if we have one way that "just works"... -- hundred-and-one symptoms of being an internet addict: 193. You ask your girlfriend to drive home so you can sit back with your PDA and download the information to your laptop /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/202003081502.028F2DM4019637%40masaka.moolenaar.net.
Re: Trying to build with MinGW
On 08-Mar-2020 00:39, Bram Moolenaar wrote: On my Windows 10 laptop I'm trying to build a non-GUI debug version with MinGW. It has a few complaints, first one is that INT_MAX was not defined. I solved that by including in vim.h. Building with the terminal feature fails with LPROC_THREAD_ATTRIBUTE_LIST undefined. I disabled FEAT_TERMINAL for now, then the linking fails with "-municode" not being defined. Is this perhaps because my MinGW version is too old? Hi Bram, Yeah I reckon it's old. I have been using mingw64 to build both vim and gvim for years now with no problems. It could be time to update. In case you were wondering, I use the latest x64 builds from here (currently gcc v9.2.1): https://gcc-mcf.lhmouse.com I've also used builds from here: https://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64 I've not tried it but I think builds from here work as well (gcc v9.1): https://nuwen.net/mingw.html For an older gcc release: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh Cheers John -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/d7300473-10b1-ddd6-093f-5afd4df16b2f%40internode.on.net.
Trying to build with MinGW
On my Windows 10 laptop I'm trying to build a non-GUI debug version with MinGW. It has a few complaints, first one is that INT_MAX was not defined. I solved that by including in vim.h. Building with the terminal feature fails with LPROC_THREAD_ATTRIBUTE_LIST undefined. I disabled FEAT_TERMINAL for now, then the linking fails with "-municode" not being defined. Is this perhaps because my MinGW version is too old? -- hundred-and-one symptoms of being an internet addict: 185. You order fast food over the Internet /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/202003071339.027DdxGk002553%40masaka.moolenaar.net.
Re: Trying to build with MinGW
Ken Takata wrote: > > [...] > > > > > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > > > > following > > > > > command to install them: > > > > > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > > > mingw-w64-x86_64-toolchain > > > > > > > > > > Or you can use the `pacboy` command to avoid long package names: > > > > > > > > > > pacboy -S base-devel: toolchain:m > > > > > > > > This asks what packages to install. Should this install "all"? > > > > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > > > > My laptop is almost full... > > > > > > If you only want to build 32-bit Vim, you don't need to install the x86_64 > > > toolchain. In this case, you can use one of the following commands: > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > or: > > > pacboy -S base-devel: toolchain:i > > > (The ":i" suffix means i686 only.) > > > > > > If you only want to build 64-bit Vim, you don't need to install the i686 > > > toolchain. In this case, you can use one of the following commands: > > > > > > pacman -S base-devel mingw-w64-x86_64-toolchain > > > or: > > > pacboy -S base-devel: toolchain:x > > > (The ":x" suffix means x86_64 only.) > > > > > > > > > Some of the package might not be needed for building Vim, but I haven't > > > checked which is necessary and which is not. > > > The above package groups are generally useful for building many kind of > > > programs. > > > > I deleted the 64 bit directory, that was 700 Mbyte. Now the 32 bit > > directory is still taking 700 Mbyte. It would be useful to find out how > > to reduce that. > > You can refer Arch Wiki for general usage of the pacman command: > https://wiki.archlinux.org/index.php/pacman > > To remove x64_86 toolchain, try: > pacman -R mingw-w64-x86_64-toolchain > or: > pacman -R toolchain:x I just deleted the directory contents, that's probably not the right way to do it. > Also you can clean the package cache. The downloaded packages are stored in > the C:\msys64\var\cache\pacman\pkg directory. > See the following part for how to clean it: > https://wiki.archlinux.org/index.php/pacman#Cleaning_the_package_cache > (Or you can remove the files manually. It is not recommended, though.) Thanks, that cleaned 330 Mbyte. I think it's pretty bad to take up so much storage. My laptop disk is 95% full Still, the 32 bit compiler takes up 750 Mbyte. We should really have instructions to make that as small as possible. People who just want to build Vim and nothing else should not need that much space on disk. -- Send $25.00 for handy leaflet on how to make money by selling leaflets /// 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.
Re: Trying to build with MinGW
Hi Bram, 2018/7/1 Sun 5:02:50 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > [...] > > > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > > > following > > > > command to install them: > > > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > > mingw-w64-x86_64-toolchain > > > > > > > > Or you can use the `pacboy` command to avoid long package names: > > > > > > > > pacboy -S base-devel: toolchain:m > > > > > > This asks what packages to install. Should this install "all"? > > > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > > > My laptop is almost full... > > > > If you only want to build 32-bit Vim, you don't need to install the x86_64 > > toolchain. In this case, you can use one of the following commands: > > > > pacman -S base-devel mingw-w64-i686-toolchain > > or: > > pacboy -S base-devel: toolchain:i > > (The ":i" suffix means i686 only.) > > > > If you only want to build 64-bit Vim, you don't need to install the i686 > > toolchain. In this case, you can use one of the following commands: > > > > pacman -S base-devel mingw-w64-x86_64-toolchain > > or: > > pacboy -S base-devel: toolchain:x > > (The ":x" suffix means x86_64 only.) > > > > > > Some of the package might not be needed for building Vim, but I haven't > > checked which is necessary and which is not. > > The above package groups are generally useful for building many kind of > > programs. > > I deleted the 64 bit directory, that was 700 Mbyte. Now the 32 bit > directory is still taking 700 Mbyte. It would be useful to find out how > to reduce that. You can refer Arch Wiki for general usage of the pacman command: https://wiki.archlinux.org/index.php/pacman To remove x64_86 toolchain, try: pacman -R mingw-w64-x86_64-toolchain or: pacman -R toolchain:x Also you can clean the package cache. The downloaded packages are stored in the C:\msys64\var\cache\pacman\pkg directory. See the following part for how to clean it: https://wiki.archlinux.org/index.php/pacman#Cleaning_the_package_cache (Or you can remove the files manually. It is not recommended, though.) > > > That uses the MSYS console, where just about nothing works. "git pull" > > > doesn't work. Can't even run the Vim I just build in it. How to build > > > Vim in a normal Windows console? > > > > When the MSYS2 console is executed, MSYS2 stops exporting the current $PATH > > by default. If you want to use git in MSYS2 console, there are two ways. > > > > 1. Change the MSYS2 setting to export the current $PATH > >See C:\msys64\msys2_shell.cmd for detail. > > 2. Install the MSYS2 version of git > >MSYS2 has its own version of git. You can install it by pacman/pacboy. > > I don't really want to use the MSYS2 console, it's like using Linux on a > Windows system. When doing "pwd" I see a different home directory, > among other surprises. I prefer using the Windows console, since that > is what most people will be using. Okay, but some other people want to use the MSYS2 console. We might be able to improve the instructions for those people. Regards, Ken Takata -- -- 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.
Re: Trying to build with MinGW
Ken Takata wrote: [...] > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > > following > > > command to install them: > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > mingw-w64-x86_64-toolchain > > > > > > Or you can use the `pacboy` command to avoid long package names: > > > > > > pacboy -S base-devel: toolchain:m > > > > This asks what packages to install. Should this install "all"? > > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > > My laptop is almost full... > > If you only want to build 32-bit Vim, you don't need to install the x86_64 > toolchain. In this case, you can use one of the following commands: > > pacman -S base-devel mingw-w64-i686-toolchain > or: > pacboy -S base-devel: toolchain:i > (The ":i" suffix means i686 only.) > > If you only want to build 64-bit Vim, you don't need to install the i686 > toolchain. In this case, you can use one of the following commands: > > pacman -S base-devel mingw-w64-x86_64-toolchain > or: > pacboy -S base-devel: toolchain:x > (The ":x" suffix means x86_64 only.) > > > Some of the package might not be needed for building Vim, but I haven't > checked which is necessary and which is not. > The above package groups are generally useful for building many kind of > programs. I deleted the 64 bit directory, that was 700 Mbyte. Now the 32 bit directory is still taking 700 Mbyte. It would be useful to find out how to reduce that. > > That uses the MSYS console, where just about nothing works. "git pull" > > doesn't work. Can't even run the Vim I just build in it. How to build > > Vim in a normal Windows console? > > When the MSYS2 console is executed, MSYS2 stops exporting the current $PATH > by default. If you want to use git in MSYS2 console, there are two ways. > > 1. Change the MSYS2 setting to export the current $PATH >See C:\msys64\msys2_shell.cmd for detail. > 2. Install the MSYS2 version of git >MSYS2 has its own version of git. You can install it by pacman/pacboy. I don't really want to use the MSYS2 console, it's like using Linux on a Windows system. When doing "pwd" I see a different home directory, among other surprises. I prefer using the Windows console, since that is what most people will be using. -- hundred-and-one symptoms of being an internet addict: 157. You fum through a magazine, you first check to see if it has a web address. /// 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.
Re: Trying to build with MinGW
Hi Bram, 2018/6/30 Sat 23:14:33 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > > 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. > > > > I set up iscygpty to use dynamic loading so that it can be executed on XP. > > Even though, it uses some definitions for Vista APIs, therefore it requires > > WINVER=0x0600. This doesn't affect other parts of Vim, so we can use other > > value for the default of WINVER (if needed). > > My point is that as it is now it doesn't build. So we should probably > make 0x0600 the default. > > > > > 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). > > > > Okay, we might need a step-by-step instruction how to setup MSYS2 for > > building Vim. The msys2 installer just installs a basic environment. > > Each user need to install GCC and other development packages by using > > the `pacman` command. > > > > > > # Setup msys2 environment for building Vim > > > > 1. Setup the basic msys2 environment > > > > Go to the official page of MSYS2: https://www.msys2.org > > Download an installer: > > > > * msys2-x86_64-MMDD.exe for 64-bit Windows > > (Even if you want to build 32-bit Vim) > > * msys2-i686-MMDD.exe for 32-bit Windows > > > > Follow the official instructions to update basic packages. Execute > > `pacman -Syu` and restart MSYS2 window (select "MSYS2 MSYS" icon from the > > Start Menu), then execute `pacman -Su`. > > If pacman complains that `catgets` and `libcatgets` conflict with another > > package, select `y` to remove them. > > > > 2. Install additional packages for building Vim > > > > The following package groups are required for building Vim: > > > > * base-devel > > * mingw-w64-i686-toolchain (for building 32-bit Vim) > > * mingw-w64-x86_64-toolchain (for building 64-bit Vim) > > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > following > > command to install them: > > > > pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain > > > > Or you can use the `pacboy` command to avoid long package names: > > > > pacboy -S base-devel: toolchain:m > > This asks what packages to install. Should this install "all"? > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > My laptop is almost full... If you only want to build 32-bit Vim, you don't need to install the x86_64 toolchain. In this case, you can use one of the following commands: pacman -S base-devel mingw-w64-i686-toolchain or: pacboy -S base-devel: toolchain:i (The ":i" suffix means i686 only.) If you only want to build 64-bit Vim, you don't need to install the i686 toolchain. In this case, you can use one of the following commands: pacman -S base-devel mingw-w64-x86_64-toolchain or: pacboy -S base-devel: toolchain:x (The ":x" suffix means x86_64 only.) Some of the package might not be needed for building Vim, but I haven't checked which is necessary and which is not. The above package groups are generally useful for building many kind of programs. > > (See `pacboy help` for the help.) > > > > 3. Keep the build environment up-to-date > > > > After you have installed the build environment, you may want to keep it > > up-to-date (E.g. always use the latest GCC). > > In that case, you just need to execute the command `pacman -Syu` once or > > twice. > > > > > > # Build Vim > > > > Select one of the following icon from the Start Menu: > > > > * MSYS2 MinGW 32-bit (To build 32-bit versions of Vim) > > * MSYS2 MinGW 64-bit (To build 64-bit versions of Vim) > > > > Go to the source directory of Vim, then execute the make command. E.g.: > > > > make -f Make_mingw.mak GUI=yes > > Hmm, I get "make: c
Re: Trying to build with MinGW
Ken Takata wrote: > > 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. > > I set up iscygpty to use dynamic loading so that it can be executed on XP. > Even though, it uses some definitions for Vista APIs, therefore it requires > WINVER=0x0600. This doesn't affect other parts of Vim, so we can use other > value for the default of WINVER (if needed). My point is that as it is now it doesn't build. So we should probably make 0x0600 the default. > > > 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). > > Okay, we might need a step-by-step instruction how to setup MSYS2 for > building Vim. The msys2 installer just installs a basic environment. > Each user need to install GCC and other development packages by using > the `pacman` command. > > > # Setup msys2 environment for building Vim > > 1. Setup the basic msys2 environment > > Go to the official page of MSYS2: https://www.msys2.org > Download an installer: > > * msys2-x86_64-MMDD.exe for 64-bit Windows > (Even if you want to build 32-bit Vim) > * msys2-i686-MMDD.exe for 32-bit Windows > > Follow the official instructions to update basic packages. Execute > `pacman -Syu` and restart MSYS2 window (select "MSYS2 MSYS" icon from the > Start Menu), then execute `pacman -Su`. > If pacman complains that `catgets` and `libcatgets` conflict with another > package, select `y` to remove them. > > 2. Install additional packages for building Vim > > The following package groups are required for building Vim: > > * base-devel > * mingw-w64-i686-toolchain (for building 32-bit Vim) > * mingw-w64-x86_64-toolchain (for building 64-bit Vim) > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the following > command to install them: > > pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain > > Or you can use the `pacboy` command to avoid long package names: > > pacboy -S base-devel: toolchain:m This asks what packages to install. Should this install "all"? It installs an awful lot of stuff, it says it uses 1.5 Gbyte. My laptop is almost full... > (See `pacboy help` for the help.) > > 3. Keep the build environment up-to-date > > After you have installed the build environment, you may want to keep it > up-to-date (E.g. always use the latest GCC). > In that case, you just need to execute the command `pacman -Syu` once or > twice. > > > # Build Vim > > Select one of the following icon from the Start Menu: > > * MSYS2 MinGW 32-bit (To build 32-bit versions of Vim) > * MSYS2 MinGW 64-bit (To build 64-bit versions of Vim) > > Go to the source directory of Vim, then execute the make command. E.g.: > > make -f Make_mingw.mak GUI=yes Hmm, I get "make: command not found". I guess I should have selected "all" when using pacboy. That uses the MSYS console, where just about nothing works. "git pull" doesn't work. Can't even run the Vim I just build in it. How to build Vim in a normal Windows console? I tried prepending "c:\msys64\usr\bin" to $PATH and that appears to work. No wait, that picks up an old MinGW version of gcc. OK, this seems to work: also prepend c:\msys64\mingw32\bin". I'll make a patch with these hints, we can further improve it afterwards. -- hundred-and-one symptoms of being an internet addict: 144. You eagerly await the update of the "Cool Site of the Day." /// 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!
Re: Trying to build with MinGW
Hi Bram, Sorry for the late reply. 2018/5/24 Thu 4:52:51 UTC+9 Bram Moolenaar wrote: > 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. I set up iscygpty to use dynamic loading so that it can be executed on XP. Even though, it uses some definitions for Vista APIs, therefore it requires WINVER=0x0600. This doesn't affect other parts of Vim, so we can use other value for the default of WINVER (if needed). > > 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). Okay, we might need a step-by-step instruction how to setup MSYS2 for building Vim. The msys2 installer just installs a basic environment. Each user need to install GCC and other development packages by using the `pacman` command. # Setup msys2 environment for building Vim 1. Setup the basic msys2 environment Go to the official page of MSYS2: https://www.msys2.org Download an installer: * msys2-x86_64-MMDD.exe for 64-bit Windows (Even if you want to build 32-bit Vim) * msys2-i686-MMDD.exe for 32-bit Windows Follow the official instructions to update basic packages. Execute `pacman -Syu` and restart MSYS2 window (select "MSYS2 MSYS" icon from the Start Menu), then execute `pacman -Su`. If pacman complains that `catgets` and `libcatgets` conflict with another package, select `y` to remove them. 2. Install additional packages for building Vim The following package groups are required for building Vim: * base-devel * mingw-w64-i686-toolchain (for building 32-bit Vim) * mingw-w64-x86_64-toolchain (for building 64-bit Vim) Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the following command to install them: pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain Or you can use the `pacboy` command to avoid long package names: pacboy -S base-devel: toolchain:m (See `pacboy help` for the help.) 3. Keep the build environment up-to-date After you have installed the build environment, you may want to keep it up-to-date (E.g.
Re: Trying to build with MinGW
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.
Re: Trying to build with MinGW
Hi Bram, 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. 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). 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. Regards, Ken Takata -- -- 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.
Re: Trying to build with MinGW
On 5/21/2018 4:50 PM, Bram Moolenaar wrote: Michael Soyka wrote: On 5/20/2018 12:30 PM, 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? In my opinion, the fundamental question appears to be should Vim continue to support the XP platform. The data structures that are generating compiler errors are defined only for Vista or later (see winbase.h). That said, I have been building 32-bit vim/gvim on an XP platform using mingw without a problem. Unbeknownst to me, I been doing that before and after the patches v7.4.2016 and v7.4.1963. If I remove the -U and -D options from the target, I get, I assume, the same compilation errors that you do. In other words, the resulting executable (with patches) works fine under XP. Perhaps some features, such as using pty's, won't work on Windows XP. Those features should be optional then. And since compiling for XP is not the most often used target, I think it's more important that the build works "out of the box". With some comments about how to make the target work on XP. I am unsure how we ended up with a Makefile that defines one WINVER in one place and another in another place, that doesn't seem right. I looked a bit more into this after I posted above. The purpose of the earlier patch apparently was to detect when vim is being launched in a mintty window and, in that case, print something that says "sorry, vim no work here". On my XP machine, vim 8.0 will not launch in a cygwin window nor in the mintty window that is packaged with "Git for Windows" nor does it print the diagnostic. This makes me think that vim is failing before it can check the terminal type (just my guess). However, version 7.4 patch 131 works fine. I have no such problem for Windows 10 with vim 8.0 launching in mintty from "Git for Windows". -mike -- -- 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.
Re: Trying to build with MinGW
Michael Soyka wrote: > On 5/20/2018 12:30 PM, 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? > > > In my opinion, the fundamental question appears to be should Vim > continue to support the XP platform. The data structures that are > generating compiler errors are defined only for Vista or later (see > winbase.h). > > That said, I have been building 32-bit vim/gvim on an XP platform using > mingw without a problem. Unbeknownst to me, I been doing that before > and after the patches v7.4.2016 and v7.4.1963. If I remove the -U and > -D options from the target, I get, I assume, the same compilation errors > that you do. In other words, the resulting executable (with patches) > works fine under XP. Perhaps some features, such as using pty's, won't work on Windows XP. Those features should be optional then. And since compiling for XP is not the most often used target, I think it's more important that the build works "out of the box". With some comments about how to make the target work on XP. I am unsure how we ended up with a Makefile that defines one WINVER in one place and another in another place, that doesn't seem right. -- Hanson's Treatment of Time: There are never enough hours in a day, but always too many days before Saturday. /// 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.
Re: Trying to build with MinGW
On 5/20/2018 12:30 PM, 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? In my opinion, the fundamental question appears to be should Vim continue to support the XP platform. The data structures that are generating compiler errors are defined only for Vista or later (see winbase.h). That said, I have been building 32-bit vim/gvim on an XP platform using mingw without a problem. Unbeknownst to me, I been doing that before and after the patches v7.4.2016 and v7.4.1963. If I remove the -U and -D options from the target, I get, I assume, the same compilation errors that you do. In other words, the resulting executable (with patches) works fine under XP. -mike -- -- 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.
Trying to build with MinGW
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? -- If you don't get everything you want, think of everything you didn't get and don't want. /// 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.
