Stefan

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,

Thank You,

Paul Gydos (p...@gydos.com)
POB 73
Burlington, NC 27216
USA
Cell +1-336-350-4234
Perm Google VM +1-336-BUZZ-212
Social Media: http://fb.com/paulgydos
Google+: http://google.com/+paulgydos


On Tue, Sep 16, 2014 at 10:19 AM, Stefan Weil <s...@weilnetz.de> wrote:

>  Hi Paul,
>
> please see my comments below.
>
> Am 14.09.2014 um 12:43 schrieb Paul Gydos:
>
>
> ---------- Forwarded message ----------
> From: Paul Gydos <p...@gydos.com>
> Date: Sun, Sep 14, 2014 at 5:57 AM
> Subject: My progress with compiling QEMU Native on W32 Win7 Pro.
> To: peter.mayd...@linaro.org
>
>
> To: Peter Maydell (peter.mayd...@linaro.org)
> From: Paul Gydos (p...@gydos.com)
>
>  Subject: Next step in compiling QEMU on W32 Win7 Pro
> have now installed GTK+ and MinGW
>
>  NATIVE BUILD OF QEMU ON W32 WIN7
>
> [...]
>
>   I downloaded the all-in-one bundle from
> http://www.gtk.org/download/win32.php
> called gtk+-bundle_3.6.4-20130921_win32
>
>
> good
>
>
>  I read this tutorial http://www.gtk.org/download/win32_tutorial.php
>
>  1) extracted files to a new folder which I named C:\gtk
>
>  2) changed my path variable by adding:
>
>    ;c:\gtk\bin
>
>
> good, too.
>
>
>  3) typed in at Command Prompt:
>
>    pango-querymodules > gtk\etc\pango\pango.modules
>
>    gdk-pixbuf-query-loaders > gtk\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
>
>    gtk-query-immodules-3.0 > gtk\lib\gtk-3.0\3.0.0\immodules.cache
>
>
>  4) tested by typing in terminal
>
>    gtk3-demo
>
>  All seemed well!
>
>  FOLLOWING UP ON PETER MAYDELL ADVICE PART 3
> NATIVE BUILD OF QEMU ON W32 WIN7
>  USE THE 32 BIT VERSION OF MINGW-W64
>
>  So to try and implement Mingw-w64 32bit version
> (http://mingw-w64.sourceforge.net/) instead of mingw32 (
> http://www.mingw.org/)
>
>
> Good. Using mingw-w64 (32 or 64 bit) is much better than using mingw32.
>
>
>
>  I'm using this tutorial
> http://sourceforge.net/p/mingw-w64/wiki2/GeneralUsageInstructions/ under
> the headings "Installing the toolchain" and "Windows native"
>
>  1) I choose the "MinGW-builds" after reading under the headings "General
> Usage Instructions" and "Downloading the toolchain" from the same tutorial
> - it seemed like a good middle of the road choice.
>
>  2) I choose "32-bit target" under the MinGW-builds heading as it seems
> to most closely correspond to my current goal which take me to
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/
>
>  3) I choose the "threads-win32" folder as it seems to most closely
> correspond to my current goal.
>
>  4) A note saying: "toolchains using DWARF for exception handling are
> also available and faster than SJLJ but you shouldn't use them unless
> you're aware of their bugs and limitations." found at:
> http://mingw-w64.sourceforge.net/download.php#win-builds
>
>  had me looking carefully between the choice of the "dwarf" or "sjlj"
> folders
>
>  I found an explanation here:
>
> http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh
>
>  and so I choose "sjlj" as it seems to most closely correspond to my
> current goal
>
>  5) From
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-win32/sjlj/
> I downloaded my SJLJ error handling Windows 32bit version of Mingw-w64
>  dated:2013-04-20 and named:
>
>  "x32-4.8.0-release-win32-sjlj-rev2.7z"
>
>  6) Extracted using 7zip to c:\mingw32 I extract the file to a new folder
> called C:\mingw32 and actually have to Ctrl-A / Ctrl-C everything in the
> folder and copy to C:\mingw32 so that the executable I need is in
> C:\mingw32\bin I also delete the original folder c:\ming32\ming32 which I
> copied the file hierarchy from 7) Changed my path variable by adding:
> ;c:\mingw32\bin 4) From the Command Prompt: i686-w64-mingw32-gcc -v result:
>  Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc
> COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/lto-w
> pper.exe Target: i686-w64-mingw32 Configured with:
> ../../../src/gcc-4.8.0/configure --host=i686-w64-mingw32 --bu
> d=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
> --with-sysroot= emp/x32-480-win32-sjlj-r2/mingw32 --enable-shared
> --enable-static --enable-tar ts=all --enable-multilib
> --enable-languages=c,c++,fortran,lto --enable-libstdc -time=yes
> --enable-threads=win32 --enable-libgomp --enable-lto --enable-graphi
> --enable-checking=release --enable-fully-dynamic-string
> --enable-version-spec ic-runtime-libs --enable-sjlj-exceptions
> --disable-isl-version-check --disable loog-version-check
> --disable-libstdcxx-pch --disable-libstdcxx-debug --disable ootstrap
> --disable-rpath --disable-win32-registry --disable-nls --disable-werr
> --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686
> --with-arch 4=nocona --with-tune-32=generic --with-tune-64=core2
> --with-host-libstdcxx='-s tic -lstdc++' --with-libiconv --with-system-zlib
> --with-gmp=/temp/mingw-prereq 686-w64-mingw32-static
> --with-mpfr=/temp/mingw-prereq/i686-w64-mingw32-static
> with-mpc=/temp/mingw-prereq/i686-w64-mingw32-static
> --with-isl=/temp/mingw-pre q/i686-w64-mingw32-static
> --with-cloog=/temp/mingw-prereq/i686-w64-mingw32-sta c
> --enable-cloog-backend=isl --with-pkgversion='rev2, Built by MinGW-builds
> pr ect' --with-bugurl=http://sourceforge.net/projects/mingwbuilds/
> CFLAGS='-O2 -p e -I/temp/x32-480-win32-sjlj-r2/libs/include
> -I/temp/mingw-prereq/x32-zlib/inc de
> -I/temp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -
> temp/x32-480-win32-sjlj-r2/libs/include
> -I/temp/mingw-prereq/x32-zlib/include
> /temp/mingw-prereq/i686-w64-mingw32-static/include' CPPFLAGS=
> LDFLAGS='-pipe - temp/x32-480-win32-sjlj-r2/libs/lib
> -L/temp/mingw-prereq/x32-zlib/lib -L/temp/
> ngw-prereq/i686-w64-mingw32-static/lib
> -L/temp/x32-480-win32-sjlj-r2/mingw32/o /lib' Thread model: win32 gcc
> version 4.8.0 (rev2, Built by MinGW-builds project)
>
>  All seemed well!
>
>  SO NOW WHAT?
>
>  As you can see I have documented what I have done as best I can as a new
> user to the environments and software technologies I am using so that there
> is not much of anything assumed and all described as specifically as
> possible and reasonable considering these are personal notes and not a
> tutorial for others (at least as of yet)
>
>  Best I can tell I need to download a QEMU tar.bz2
> Can I use one of these? http://wiki.qemu.org/Download
>
>  Either
> * qemu-2.1.1.tar.bz2
> * qemu-2.0.2.tar.bz2
>
>  or do I need to get another version from github - and if I do need
> another version from github can I use git with my current setup or so I
> need to add git to it?
>
>  Can I decompress these inside my windows file hierarchy in C:\ ?
> Can I do it within the Command Prompt System now that I have my path
> assigned as described in PART 2 and PART 3
>
>  Should I drop these into a new folder C:\qemu ? Is that a bad strategy?
>
>
> That should be fine.
>
>   What would be the exact commands to expand these files considering the
> windows file hierarchy rather than a linux hierarchy or do I still have to
> get msys and run it in a linux hierarchy (prefer 1st option if possible)
>
>
> You won't be successful with your preferred option (at least not without
> much work). Use msys.
>
>
>  Do I need to modify my path further for gcc to work from the Windows
> Command Prompt? What would I type exactly at the end of my current path?
>
>  How do I configure and make in this situation? (Considering the windows
> file hierarchy or again do I need to use msys? I prefer the first over the
> lattter option).
>
>
> See above.
>
>
>  Am I already a root user?
>
>
> On Windows? No. You are "paul" or whatever your Windows account is.
>
>
>
>  I'm hoping this can all be done from the Command Prompt instead of using
> msys but I'm open to anyone's instructions as long as they are current (Its
> September 14th 2014 when I wrote these notes.
>
>  Peter, I hope you might have further advice for this terrible noob. I'm
> going to also post what I have so far wherever I can figure out where to
> post it and get advice and email it to anyone who I think might give me an
> answer also.
>
>  I'm also hoping to continue on this path rather than a whole other
> solution but I am willing to deviate again at the point of PART 3 if
> getting another 32 bit version of MinGW-W64? Actually I'm willing to follow
> any simple directions. I hope you see I have given it my own time and
> effort - It doesn't seem as though there are current documentation
> available for a newer native build on W32 right now so if someone can help
> me see it through to the end I will rewrite it yet futher and post to all
> relevant parties where current documentation aught to exist
>
>  Thank You,
>
>  Paul Gydos (p...@gydos.com)
>
>
> Regards
> Stefan Weil
>
> PS. My binaries on http://qemu.weilnetz.de/ are cross compiled on Debian
> GNU Linux. I don't compile often on Windows because it is much slower.
>
>

Reply via email to