[Qemu-devel] [Bug 1276847] [NEW] Build fails on latest MinGW

[Qemu-devel] [Bug 1276847] [NEW] Build fails on latest MinGW

[Corry Lazarowitz]

Public bug reported:

I've run across all sorts of problems.  The first was simple, warnings
treated as errors, and a warning of -fPIC ignored because its generating
all code as position independant.  Next came the %hhx's everywhere.
MinGW is apparently following old MSVC non-C99 compliant systems, and
hhx is not defined.  Again, warnings as errors killed the build.  zlib
can never be found, for some reason I have to add a -I /include.  %llx
is also not recognized on mingw, but MinGW does have inttypes.h, so
those could easily be converted to PRIx64's with a regex.  asprintf is
not included in MinGW, used in srcpos.c only so far, so I added an
implementation in my build driectory which I found online.  lstat is not
part of mingw, and ntfs's links are different anyhow, so I #defined
lstat to stat.  fnmatch is included in libiberty, so I had to frab
fnmatch.h from MinGW's sourceforge and then add the -liberty statement
to the makefile.

I get the feeling though, based on the number of warnings I'm seeing
flash across as the compiler attempts to go through this that there are
going to be more errors to fix. Catching the initial errors was quite
tough because for some reason in pixman and dtc the errors couldn't
cause compilation to stop, and running make again wouldn't attempt to
rebuild the failures.  I had to watch it like a hawk and ctrl-c it when
I saw an error until I finally got a build!

For reference, my build system looks like:

User@Computer /c/projects/qemu-1.7.0
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

I'm not wonderful with making patches, and most of what I've done I've
not properly guarded against other OS's either, but if you want,
assuming I ever get it to build, I can post the patch of all the changes
I made...

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions

[Qemu-devel] [Bug 1276847] Re: Build fails on latest MinGW

[Stefan Weil]

QEMU for MinGW does not use fnmatch. There is also no asprintf in latest
QEMU, only in dtc where it does no harm. The build for MinGW does not
use -Werror (for good reason). And yes, MinGW is broken and complains
about most format string. Just ignore these warnings, it will work
nevertheless.

If you want a better build environment for Windows, use MinGW-w64. It
also allows 32 and 64 bit builds.

To make it short: the current code works without any patch if you
configure QEMU with --enable-debug. There is a known problem with
coroutines which will make QEMU fail during file operations if it was
compiled with optimisations.

Regards
S. W.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions

[Qemu-devel] [Bug 1276847] Re: Build fails on latest MinGW

[Corry Lazarowitz]

Ok, so I figured perhaps my initial attempts with cygwin were the issue,
and perhaps that made it much worse than it should have been.  So I
moved the directory and decompressed the archive again, started with
./configure, but as you said (which I didn't see in the docs) I added
--enable-debug.  So far so good, go into make, which runs configure on
pixman, and thats where I had the first error.  I'm not really sure
what's supposed to be here, but here is the error with a little
context...

checking whether to use MMX intrinsics... yes
checking whether to use SSE2 intrinsics... yes
checking whether to use VMX/Altivec intrinsics... no
checking whether to use ARM SIMD assembler... no
checking whether to use ARM NEON assembler... no
checking whether to use GNU-style inline assembler... yes
/c/projects/qemu-1.7.0/pixman/configure: line 12454: PKG_PROG_PKG_CONFIG: command not found
/c/projects/qemu-1.7.0/pixman/configure: line 12456: syntax error near unexpected token `gtk+-2.0,'
/c/projects/qemu-1.7.0/pixman/configure: line 12456: `   PKG_CHECK_EXISTS(gtk+-2.0, enable_gtk=yes, enable_gtk=no)'
make: *** [pixman/Makefile] Error 2

Here is the offending section

PKG_PROG_PKG_CONFIG
if test $enable_gtk = auto ; then
   PKG_CHECK_EXISTS(gtk+-2.0, enable_gtk=yes, enable_gtk=no)
fi
if test $enable_gtk = yes ; then
   PKG_CHECK_MODULES(GTK, gtk+-2.0)
fi

 if test "x$enable_gtk" = xyes; then
  HAVE_GTK_TRUE=
  HAVE_GTK_FALSE='#'
else
  HAVE_GTK_TRUE='#'
  HAVE_GTK_FALSE=
fi

Just in case its relevant, here is the output from autotools before running configure...
configure.ac:552: the top level
configure.ac:69: installing `./config.guess'
configure.ac:69: installing `./config.sub'
configure.ac:62: installing `./install-sh'
configure.ac:62: installing `./missing'
pixman/Makefile.am: installing `./depcomp'
autoreconf-2.68: Leaving directory `.'
(cd pixman; CFLAGS="-g  -fPIC -m32  " /c/projects/qemu-1.7.0/pixman/configure  --disable-gtk --disable-shared --enable-static)

I'm not an autotools guy, but I'm guessing PKG_PROG_PKG_CONFIG is
supposed to have resolved to something else in autotools.  I've never
had to develop something that needed to run on a wide range of platforms
without QT (qmake) or cmake, so I never ventured into autotools....

Since I can see at least for the mingw version, disable-gtk is passed,
so I just took the section out, and manually set it to no with the
following replaced section.

#PKG_PROG_PKG_CONFIG
#if test $enable_gtk = auto ; then
#   PKG_CHECK_EXISTS(gtk+-2.0, enable_gtk=yes, enable_gtk=no)
#fi
#if test $enable_gtk = yes ; then
#   PKG_CHECK_MODULES(GTK, gtk+-2.0)
#fi
#
# if test "x$enable_gtk" = xyes; then
#  HAVE_GTK_TRUE=
#  HAVE_GTK_FALSE='#'
#else
  HAVE_GTK_TRUE='#'
  HAVE_GTK_FALSE=
#fi

I suppose this may also be a source of more errors, but I think this is
pretty foolproof here.  It said --disable-gtk so, it should pretty much
be a no brainer...

It seems like perhaps I was still thinking I could use cygwin up to this
point, because I don['t have treat warnings as errors anymore.  I must
have run into problems with cygwin after this point, and decided it
might just be easier to use mingw since I remember seeing things to set
target os in one of the configure scripts, cygwin wasn't an option, but
mingw was, which made me decide to switch.  Sorry, I don't remember
where that was....

Next error comes in linking qemu-img with the following block of errors...
  LINK  qemu-img.exe
block.o: In function `bdrv_set_dirty_tracking':
c:\projects\qemu-1.7.0/block.c:4367: undefined reference to `ffs'
block/qcow2-refcount.o: In function `qcow2_pre_write_overlap_check':
c:\projects\qemu-1.7.0/block/qcow2-refcount.c:1776: undefined reference to `ffs'
block/qcow2.o: In function `qcow2_create2':
c:\projects\qemu-1.7.0/block/qcow2.c:1452: undefined reference to `ffs'
block/qed.o: In function `bdrv_qed_open':
c:\projects\qemu-1.7.0/block/qed.c:430: undefined reference to `ffs'
c:\projects\qemu-1.7.0/block/qed.c:432: undefined reference to `ffs'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x691): undefined reference to `_impure_ptr'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x140a): undefined reference to `_impure_ptr'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x1520): undefined reference to `_impure_ptr'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x15fc): undefined reference to `_impure_ptr'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x1632): undefined reference to `_impure_ptr'
C:/MinGW/msys/1.0/lib/libiberty.a(getopt.o):getopt.c:(.text+0x166b): more undefined references to `_impure_ptr' follow
collect2.exe: error: ld returned 1 exit status
make: *** [qemu-img.exe] Error 1

This is different than what I had before.  I don't remember anything
about ffs, so at this point, its not my cygwin attempt mucking things
up.  Anyhow, I'll keep trying to plow through this, but it does not work
smoothly on the latest MinGW/MSYS, as this was a brand new computer and
a fresh pull of MinGW/MSYS.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions

[Qemu-devel] [Bug 1276847] Re: Build fails on latest MinGW

[Stefan Weil]

cygwin builds are not supported and don't work with the current code.

A fresh pull of MinGW/MSYS is not sufficient. You will also need
glib-2.0, maybe pdcurses, sdl or even gtk-2.0 and other additional
software. You will also need pkconfig (part of the all-in-one installer
for gtk-2.0).

As I said before, MinGW-w64 is a better choice than MinGW because its
include files are better maintained, so I suggest using MinGW-w64.

Please note also that QEMU on Windows always runs without hardware
acceleration, so it will be much slower than native code.

Stefan

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions

[Qemu-devel] [Bug 1276847] Re: Build fails on latest MinGW

[Corry Lazarowitz]

I do understand  dependencies :)  I just didn't think it was necessary
to list that all out.  However, this clearly isn't a dependancy issue!
(Unless you are saying I have to use autoconf 2.5 or something instead
of the current 2.68).  I grabbed glib, devel stuff, pkgconfig, etc.  Its
all setup.  Paths to mingw in msys setup.  All the work to get things
going are done.

Now, if what you're really saying is that no one works with the 32 bit
version anymore, and so its basically unsupported, I'll grab the x64
msys....its just a hassle because internet access is slow here.  I am an
assembly optimizer, so I fully understand the benefits of x64.  I also
know very well QEMU is software only.  I'm actually looking to emulate
ppc to become a little more familier with the architecture before I have
actual hardware to play with.  I understand there is a wide range of PPC
hardware, but the instruction set is still roughly similar.Given that
its RISC I'm not sure exactly what I'm going to be able to do in
assembly to speed things up unless when I get to my target platform I
find the compiler is terrible at register management or something
equally silly.  (Its terrible on x86!  So many performance gains can be
had just by using ecx/rcx for something other than a loop counter when
there isn't a loop going on! but I digress).

Anyhow, if you do a fresh pull, grab dependencies, and get the build env
all setup, you should see the same error starting with the autoconf
issue.  I'm still yet to figure out the undefined reference to
_impure_pointer issue...most pages that talk about it are in the context
of cygwin, and I havent touched cygwin since deleting the directory and
re-extracting the archive.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions

[Qemu-devel] [Bug 1276847] Re: Build fails on latest MinGW

[Corry Lazarowitz]

Well, despite those very real error messages I had, its gone now with a
full msys reinstall.  Same dependencies for 32 bit.  I just decided to
try the 64 bit since to me it seemed like you were saying that would be
more likely to work.  As part of installing the 64 bit, I decided to
incur more pain and sort mingw by 32 bit and 64 bit directories.  Since
I didn't know what dependencies on directory structure may exist
internally, I just blew it all away and reinstalled both 64 and 32 bit.
64 bit QEMU built, so I went back and tried 32, and no problem with
configure.  In x64 I had to enable the built in ffs again, and I suspect
I'll have to do that in 32 bit as well if I want to build it, but since
configure worked this time, I am guessing something went wrong with the
msys/mingw install.  I don't normally use mingw, so this was the first
project I had tried to compile with it.  I did't keep any of the old
mingw so I can't test that theory, but its the best I've got!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1276847

Title:
  Build fails on latest MinGW

Status in QEMU:
  New

Bug description:
  I've run across all sorts of problems.  The first was simple, warnings
  treated as errors, and a warning of -fPIC ignored because its
  generating all code as position independant.  Next came the %hhx's
  everywhere.  MinGW is apparently following old MSVC non-C99 compliant
  systems, and hhx is not defined.  Again, warnings as errors killed the
  build.  zlib can never be found, for some reason I have to add a -I
  /include.  %llx is also not recognized on mingw, but MinGW does have
  inttypes.h, so those could easily be converted to PRIx64's with a
  regex.  asprintf is not included in MinGW, used in srcpos.c only so
  far, so I added an implementation in my build driectory which I found
  online.  lstat is not part of mingw, and ntfs's links are different
  anyhow, so I #defined lstat to stat.  fnmatch is included in
  libiberty, so I had to frab fnmatch.h from MinGW's sourceforge and
  then add the -liberty statement to the makefile.

  I get the feeling though, based on the number of warnings I'm seeing
  flash across as the compiler attempts to go through this that there
  are going to be more errors to fix. Catching the initial errors was
  quite tough because for some reason in pixman and dtc the errors
  couldn't cause compilation to stop, and running make again wouldn't
  attempt to rebuild the failures.  I had to watch it like a hawk and
  ctrl-c it when I saw an error until I finally got a build!

  For reference, my build system looks like:

  User@Computer /c/projects/qemu-1.7.0
  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=C:\mingw\bin\gcc.exe
  COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
  Target: mingw32
  Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
  Thread model: win32
  gcc version 4.8.1 (GCC)

  I'm not wonderful with making patches, and most of what I've done I've
  not properly guarded against other OS's either, but if you want,
  assuming I ever get it to build, I can post the patch of all the
  changes I made...

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1276847/+subscriptions