PGTS Humble Blog
Thread: Open Source Software
|This guy has got to go! -- Malcolm Turnbull, September, 2015.|
Installing MinGW [32-bit]
Chronogical Blog Entries:
Date: Mon, 31 Dec 2018 23:00:00 +1100
For several years, I have had the item "Check out MinGW GCC" on my TODO list ... finally I got round to it before it ended up being on my "bucket list" ...
I've been using products generated by or alongside MinGW for many years ... Cygwin is probably the product that comes to mind first. It has been converging with MinGW, especially since the 64-bit version. And of course, Strawberry perl also comes to mind. It ships with a working MinGW C compiler, tricked out for Strawberry. So I decided to go and look for the full version of MinGW ... A Google search took me to http://www.mingw.org/ ... But before going the "Full Monty", I thought it might be prudent to set it up in it's own folder, and maybe create a couple of environments, one for the Windows CMD prompt and another for the BASH shell (which according the information on www.mingw.org, could be included if I dowlnaded MSYS (a cut down version of BASH And a unix environment using native Windows APIs)
I followed the installation instructions for both MinGW and MSYS and after studying it for a little while, came up with the following simple batch file:
@echo off echo. echo MinGW environment set choice /m "Call bash" set reply=%errorlevel% PATH=c:\Program Files (x86)\Vim\vim80;C:\Strawberry\perl\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Strawberry\perl\site\bin;C:\WINDOWS\System32\OpenSSH;C:\Users\uname\bin if %reply% equ 1 ( title MinGW BASH call C:\MinGW\msys\1.0\bin\bash.exe --init-file c:/Users/uname/bin/profile.bash ) else if %reply% equ 2 ( title MinGW CMD call C:\Windows\System32\cmd.exe /K "cd %userprofile%" )
This allowed me to experiment with a version that used the Windows native CMD and the GNU bash shells. The PATH was created for the CMD shell. The bash PATH was over-ridden by the init-file [c:/Users/uname/bin/profile.bash], which fulfilled the function of .profile [when invoked with --login] ... If you decided to go down a similar route you'd have to tailor the PATH and the init-file for your installation. Obviously my login name was not "uname" [substitute actual login name here]
A few observations:
- It seemed to be a 32-bit application! With a little researcxh I discovered the 64-bit version ... Still I was puzzled about why the 32-bit version came up first in the Google search (more about this later).
- The speed of some commands was slow (possibly due to the fact that they used several old 32-bit libraries). This has always been a problem for applications that try to implement Unix tools over native Windows APIs. I also had a feeling that the speed might improve if I installed MinTTY. I had found several comments online that MinTTY was an option with MinGW -- And I always consdired that the inclusion of MinTTy in the standard Cygwin distribution seemed to make a big difference to the overall "feel" of Cygwin.
- In order to get something in /usr, the MinGW team have simply remounted the root system in /usr. In the installation I had just setup, the root was C:\MinGW\msys\1.0 ... According to "mount" this was mounted on both "/usr" and "/". It's possible they got this idea from Cygwin which does something similar with "/bin" and "/lib".
- The "ln" command did not seem to create soft links when invoked with the -s switch. Also any of the links created did not show up in a directory listing (with the "ls" command) or the Windows "dir" command. I got better results with the Windows "mklink" command (but the link still would not show in the GNU "ls" commmand).
So having dipped my toes into MinGW waters, I decided to jump in with both feet, and give it whirl. I ditched my simple script and created shortcuts for both MinGW CMD and MinGW BASH. For BASN, the recommended approach was to use the MSYS launcher. This involved making a shortcut on the dekstop to this command: C:\MinGW\msys\1.0\msys.bat.
Everything went quite well. However I did encounter some more problems with links, which persuaded me to get rid of the "ln" command altogether. The version of ln was as follows:
ln (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law.Whenever I invoked it with the "-s" option it seemed to create a "hard link" rather than a symbolic link. And in the case of folders this was concerning. I had forgotten about my early encounters with "ln" in my first impressions and my fingers had entered the command to create a link symbolic link to a remote SMB folder before my brain had time to think about it. The command took a very long time ... (Finally my tired old brain kicked in and came up with the thought --- Oops!) ... It seemed to be parsing the entire folder, sub-folders and all files in the sub-folders and creating a local copy of them on my hard disk! Not what I wanted at all! Even though I was fairly certain that this is what it had done, I was (understandably) reluctant to try and remove the folder for fear that this might delete the entire contents of the original mount. As I discovered later, I need not have worried ... However since this was my first encoutner with the issue, I took a cautious approach. Since I had used a link to mapped drive (rather than the actual sharename, I deleted all my mapped drives that referenced the SMB server (using the /delete option on "net use") and then removed the local folder. I then re-created the mapped drives and used the Windows mklink command to create a (directory) symbolic link to the SMB share. After this I set about getting rid of the ln command be renaming it to ln.exe.donot_use and replacing "ln" with a shell script that echoed the words "ERROR: 'ln' is not available -- Use 'mklink' from the Windows CMD prompt instead". Probably this will be fixed in a future release. For the time being it was an adequate work-around.
Next I went looking for a version of MinTTY. The initial results I found recommended that I use the GUI installer to fetch it. However this didn't work for me ... I searched through the packages in the GUI installer but it seemed to me like searching for a needle in a haystack ... Instead a google search for command lines that would fetch MinTTY in MSYS returned some information about an MSYS command called mingw-get. A little reading convinced me that this was the command I was looking for. The mingw-get command is a very basic all in one package manager. Not nearly as sophisticated as the Linux APT, but quite reasonable. You can get a list of the packages by using the "list" command on the command line. And if you prefer you can use a GUI interface. After a litte study, I ran the following:
mingw-get install minttyThis installed a version of MinTTY. compatible with MSYS version I had installed. You can get help by calling MinTTY from the command line with the --help option. Using the information in the help window, and by trial and error, I came up with the following shortcut on the desktop:
C:\MinGW\msys\1.0\bin\mintty.exe -t "MinGW BASH" -e C:\MinGW\msys\1.0\bin\bash.exe --login
This will call your .profile (in $HOME). You can configure a large number of additional options in the MinTTY options submenu (Right-click the menu bar on your MinTTY session, after you have launched it from the shortcut).
Note: according to the comments in msys.bat, you could also add the --mintty option when calling msys.bat ... This would mean that your shortcut referenced msys.bat rather than MinTTY. I didn't test this ... But it all looks ridgi-didge. (The script msys.bat is in the msys root)
My overall impression was that MinGW was a robust and comprehensive package that contained most of the unix tools that are standard fare for a regular unix command line user. However since it is a 32 bit it will remain frozen in its current form like an insect fossilized in amber, until it eventually fades into obscurity. This left me wondering, why did I not find information about the 64-bit release at the top of my Google search?
To a certain extent it may have been my inital search? I can't recall exactly what it was ... Although, after I checked out the 64-bit version, I started to think that there may be another reason ... The 32-bit version is a well integrated package with it's own dedicated website. On the other hand, the 64-bit version is a chaotic and untidy mess ... Dom't get me wrong ... The software is excellant, but most of it is currently in development and there is not much in the way of a coherent over-view.
Obviously anyone serious about MinGW would have to use the 64-bit version. So I set about investigating MinGW64. And that will be the topic of my next blog.