Ok, so then as I now have two rather impressive people advising to go the Mingw-w64 route - I have found no auto-installer al la the Mingw32 which does a nice job of bundling in a bunch of stuff to make msys work and options to add C and C++ library etc -
(In fact since I wrote this to Peter I had gone back to Mingw32 and the auto installer and came next upon needing Python in my toolchain in order to execute ./configure from mys from the correct path - this particular point is moot since I will be going back to trying to build my tooldhain with Mingw-w64 and there may be that plus many other considerations. It was interesting to see what POSIX-like commands worked in Command Prompt and what worked in MSYS - I found where my linux-like hierarchy resided within the Windows file hierarchy and also how to address locations outside of that hierarchy in msys by adding \c\ in front of the path I could point anywhere while anything else \ started in the linux-like hierarchy created inside the appropriate MSYS)
So unless there is an auto-installer built using mingw-w64 32 bit version (in my case) - there is the challenge of mimicking what happens there but manually - I didn't find great documentation on msys intallation with mingw-w64 as of yet.
I however am I compiling a list of various documentations both for those who have done this with older QEMU so I can evaluate their various advice and clues, then organize each of the considerations and philosophies into an outline and approach the project in an organized fashion rather than just hit or miss troubleshooting - looking for the next step - As I noted on the qemu-discuss list - I find Mike Levin's article from about going down this path unsuccessfully rather interesting also - http://mikelev.in/2012/10/compiling-qemu-for-windows-help/
- sometimes there is much to be learned by people who walked the paths unsuccessfully as those walked it successfully.
So I did wonder if your Windows binaries had been cross-compiled - so thanks for letting me know that they were so by and large. So now I know more clearly what a stubborn path I'm going - ultimately I get the "reward" of compiling more slowly - since apparently you have done it before in the past for you to be able to compare performance. What you say makes perfect sense.
What probably isn't sensible is that I'm now taking this seriously enough to actually organize as a project - I think if outline the project in potential steps and considerations it will be easier to get checklist like reaction of down the right path or not and help elicit other specific helpful advice. Well that does sound sensible, but with exception to what seems like a silly goal. However, Iin the end I'm learning about building imported toolchains and dependencies using a combination of manually tasks and automated installers; also I'm learning how to communicate with a community, and I will be learning how to organize a project. So this is not a bad activity for me who is otherwise bored to tears by some of the work I do to pay the bills.
Also I need to organize my learning on a different note on using the QEMU tool - Initially I may be most interested in things I will initially need to learn to accomplish my qoals with the little learning system for learning Python2, Git, and Vi (Ironically I confess to having very little experience in each of them but at least I get very lit argument about git; whoa text editors and programming languages elicit explosive reactions at mere mention) - I will need to convert the iso to qcow2 probably. I want to make one of those nifty launch right into a QEMU window - with already chosen settings and launch the little derived-from-4MLinux-Core-OS-spin - graphically represented and all in one little small footprint file download and click into machine - probably a .vbs script plus the QEMU virtualmachine and the system image bundle)
I appreciated your feedback,
Burlington, NC 27216
Perm Google VM +1-336-BUZZ-212