Menu
▾
▴
#1218 Installer Fails to Download "MinGW base tools"
Hi:
I tried to install MinGW with MinGW-5.1.4.exe yesterday (November 1, 2008), and it fails at the download stage. I am running Windows XP with SP2. The steps to reproduce this problem are:
1) Run installer
2) Choose "Download and install" or "Download only" (the problem appears either way)
3) Choose "Current" package
4) Select any type of install that includes "MinGW base tools". The simplest would be, of course, a "Minimum" install.
5) Select a download location. It doesn't matter whether it has a space or not (for this bug).
6) The download process will almost immediately fail with something like "Connection appears to have dropped. Please check your dial-up settings or IE proxy settings."
It will fail no matter how many times you click "Retry".
I downloaded the source code for the installer, and looking at the file mingw.nsi (I'm not sure what language this is written in, so bear with me), it appears the problem is in the file parsing code. Specifically, in the function ChoosePackage, there is the following code, presumably to extract the names and sizes of the various tarballs:
ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "runtime"
${If} $R0 == ""
ReadINIStr $R0 "$EXEDIR\mingw.ini" current "runtime"
${EndIf}
${StrTok} $runtime $R0 "|" 0 0
${StrTok} $R1 $R0 "|" 1 0
SectionSetSize ${SecRuntime} $R1
ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "w32api"
${If} $R0 == ""
ReadINIStr $R0 "$EXEDIR\mingw.ini" current "w32api"
${EndIf}
${StrTok} $W32API $R0 "|" 0 0
${StrTok} $R1 $R0 "|" 1 0
SectionSetSize ${SecW32API} $R1
If you then take a look at the init file mingw.ini, you will see that for the "Current" package (make sure you look at the file after running the installer so that you have an updated version), there are 2 problems:
1) There is more than one "runtime" entry, and moreover, they are called "runtime-dev" and "runtime-dll"
2) The "w32api" entry is actually called "w32api-dev".
If you attempt to download the "Previous" package, everything will work, because, looking at mingw.ini again, the "runtime" and "w32api" entries are in the format that the parsing code expects. The "Current" package also works if you change the appropriate mingw.ini entries as the installer is running.
In terms of solving it, I'm guessing you could either make the parsing code more robust by only matching the beginning of the entry name instead of the whole name, and looping over all entries instead of assuming a singly entry (e.g., look for all entries which begin with "runtime"). Of course, you could instead make server-side changes as to how the entries are named (e.g., make sure there is only one "runtime" entry and that its actually called "runtime").
Well anyways, I'm sure you guys will have no problems solving this :D
Thanks for your wonderful work,
GodFall
Discussion
This issue has come about because of the split up of mingwrt*-dev and mingwrt*-dll, we require both. Thanks for the bug report; I hope you have time to test for me.
BTW the language is NSIS (see nsis.sf.net).
Hmm, interesting. If I'm not mistaken, Nullsoft is involved with WinAmp right?
What further testing do you require? Or do you mean testing once you have a solution? In either case, I have time (its pretty easy to reproduce :D).
I was even thinking of fixing it myself - I guess the only thing stopping me was an uncertainty about the best approach. In other words, fixing it so that it works for now is pretty simple, but fixing it with an eye towards the future (i.e., future changes to the name/quantity of the tarballs) is not so simple.
Cheers,
GodFall
I have a simple workaround in place. I uploaded a file mingwrt-3.15.1-mingw32.tar.gz that combines the -dev and -dll files. I then modified and uploaded a new mingw.ini file. Can you test this workaround, please? My proxy settings are in the way for me to test right at the moment.
Improving the installer is already under way by John E. (tdragon) with a new package in CVS called mingw-get. You might want to offer assistance to him. As for the current installer, I'll probably release a fix just to handle our new file name formatting and to hopefully fix the proxy issue. Therefore, I'm leaving this issue open.
There seems to be a typo in the updated ini file, I have
runtime=mingw-3.15.1-mingw32.tar.gz|560294
but the file is called mingwrt-3.15.1-mingw32.tar.gz
But even after fixing the ini file (after the installer has downloaded it, as suggested in the original bug report), the download doesn't proceed - even though the URL seems correct (when I tried typing http://downloads.sourceforge.net/mingw/mingwrt-3.15.1-mingw32.tar.gz into a browser, I got a download).
Correction: after fixing the line, I was able to download the runtime but only on the second or third attempt. Repeatedly hitting "retry" fixes this, apparently Sourceforge has some problems with it's mirrors (this happens in my browser too). (disabling my firewall didn't help with this).
Thanks for the report about the typo. For the mirror issue, you might try setting your SF account with a default mirror.
Is setting a mirror going to help when downloading via the installer? I always thought this affects only how things go when I'm using a browser. But thanks for the suggestion - I thought I had a default mirror picked, but with SF moving things around, it's probably gone stale.
Thanks to ernie for the fix and cynebeald for testing the fix. I just got home, and can confirm that the fix works (the mingw.ini file for the "Current" release looks good now).
Keep up the good work,
GodFall
ernie, cynebeald:
Try changing the IP of downloads.sf.net to a known good mirror in your HOSTS file. That will affect all programs which try to connect, not just your browser. Of course if SF are moving things around, that might not be such a great idea.
I've changed de url in the "ini" file with this one obtained from one of the comments by "cynebeald": (http://downloads.sourceforge.net/mingw/), and it worked. Although sometimes you must click on retry, the installation finished well. Sorry for my bad english.