[Qemu-devel] MinGW build

[Qemu-devel] MinGW build

[Liviu Ionescu]

since I had some troubles to build QEMU on Windows, I compiled a page with some instructions:

	http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows

the purpose was to generate a standalone executable, that requires no libraries.


although the procedure is fully functional, I had to apply a small patch, basically:

#ifdef __MINGW32__
    #if !defined(ffs)
    #define ffs __builtin_ffs
    #endif
#endif

in several files.


- any suggestions on how to simplify the MinGW build procedure?

- anyone interested in this patch?


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 26 November 2014 at 19:55, Liviu Ionescu <ilg@livius.net> wrote:
> since I had some troubles to build QEMU on Windows, I compiled a page with some instructions:
>
>         http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows
>
> the purpose was to generate a standalone executable, that requires no libraries.
>
>
> although the procedure is fully functional, I had to apply a small patch, basically:
>
> #ifdef __MINGW32__
>     #if !defined(ffs)
>     #define ffs __builtin_ffs
>     #endif
> #endif
>
> in several files.

Hmm. We have a workaround already for a similar thing in
include/sysemu/os-win32.h,
but that works by declaring a prototype rather than using a #define, and it's
guarded by defined(_WIN64). I wonder if some of those workarounds in that file
need to be guarded by more specific checks than just _WIN64...

Do you have any experience with mingw-w64? When I was doing Windows
(cross-compiled) builds mingw-w64 seemed to be more actively maintained
(even for 32 bit windows targets) than the original mingw project,
and I think there was at least one issue where the fix was basically
"don't try to use mingw, it's just too old, use mingw-w64 instead".

In any case, thanks very much for writing up the instructions -- we do
get people wanting to know how to build on Windows from time to time,
so it will be useful to be able to point them at instructions.

You might consider tweaking the instructions to recommend building in
a subdirectory (ie 'mkdir -p build/windows; cd build/windows;
../../configure; make'). This is good if you're going to be building
more than one configuration, and it also makes it easy to blow away
an old build by removing the whole build tree (distclean is not always
100% reliable especially if you track head-of-git often).

-- PMM

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 26.11.2014 um 21:13 schrieb Peter Maydell:
> On 26 November 2014 at 19:55, Liviu Ionescu <ilg@livius.net> wrote:
>> since I had some troubles to build QEMU on Windows, I compiled a page with some instructions:
>>
>>         http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows
>>
>> the purpose was to generate a standalone executable, that requires no libraries.
>>
>>
>> although the procedure is fully functional, I had to apply a small patch, basically:
>>
>> #ifdef __MINGW32__
>>     #if !defined(ffs)
>>     #define ffs __builtin_ffs
>>     #endif
>> #endif
>>
>> in several files.
> 
> Hmm. We have a workaround already for a similar thing in
> include/sysemu/os-win32.h,
> but that works by declaring a prototype rather than using a #define, and it's
> guarded by defined(_WIN64). I wonder if some of those workarounds in that file
> need to be guarded by more specific checks than just _WIN64...
> 
> Do you have any experience with mingw-w64? When I was doing Windows
> (cross-compiled) builds mingw-w64 seemed to be more actively maintained
> (even for 32 bit windows targets) than the original mingw project,
> and I think there was at least one issue where the fix was basically
> "don't try to use mingw, it's just too old, use mingw-w64 instead".
> 
> In any case, thanks very much for writing up the instructions -- we do
> get people wanting to know how to build on Windows from time to time,
> so it will be useful to be able to point them at instructions.
> 
> You might consider tweaking the instructions to recommend building in
> a subdirectory (ie 'mkdir -p build/windows; cd build/windows;
> ../../configure; make'). This is good if you're going to be building
> more than one configuration, and it also makes it easy to blow away
> an old build by removing the whole build tree (distclean is not always
> 100% reliable especially if you track head-of-git often).
> 
> -- PMM
> 


I was just writing nearly the same as Peter. So now I can only add one
remark: there is also a QEMU Wiki which has some rather old instructions
on building for Windows: http://wiki.qemu.org/Hosts/W32. Maybe you could
add updated / new instructions there.

Thanks
Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 26 Nov 2014, at 22:13, Peter Maydell <peter.maydell@linaro.org> wrote:

> ... We have a workaround already for a similar thing in
> include/sysemu/os-win32.h,

ok, I'll investigate.

> Do you have any experience with mingw-w64?

unfortunately not, but, time permitting, I'll check it.

> In any case, thanks very much for writing up the instructions -- we do
> get people wanting to know how to build on Windows from time to time,
> so it will be useful to be able to point them at instructions.

you're welcome! 

I'll try to keep the GNU ARM Eclipse wiki as up-to-date as possible.

> You might consider tweaking the instructions to recommend building in
> a subdirectory...

right, that's a very good idea, I did not know that configure can do this.

I already updated the wiki.


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 26 Nov 2014, at 22:13, Peter Maydell <peter.maydell@linaro.org> wrote:

> Hmm. We have a workaround already for a similar thing in
> include/sysemu/os-win32.h,
> but that works by declaring a prototype rather than using a #define, and it's
> guarded by defined(_WIN64). I wonder if some of those workarounds in that file
> need to be guarded by more specific checks than just _WIN64...

I reverted my patch and created another one based on your workaround, with the following changes:

in os_win32.h:

/* Declaration of ffs() is missing in MinGW's strings.h. */
#ifdef __MINGW32__
#define ffs __builtin_ffs
#else
int ffs(int i);
#endif

in qemu-common.h:

#ifdef _WIN32
#include "sysemu/os-win32.h"
#endif

#ifdef __MINGW32__
#include "sysemu/os-win32.h"
#endif


with these two changes the build with MinGW-32 passes.

---

another build procedure with MinGW-64 is considered; if successful, the steps will be described in the GNU ARM Eclipse wiki.

---

however, not related to the above, the build shows tens, maybe hundreds of warnings, most of them -Wformat, but also many -Wformat-extra-args.

perhaps someone with a good knowledge of the code could take a look at these warnings.


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 27 November 2014 at 16:43, Liviu Ionescu <ilg@livius.net> wrote:
> in qemu-common.h:
>
> #ifdef _WIN32
> #include "sysemu/os-win32.h"
> #endif
>
> #ifdef __MINGW32__
> #include "sysemu/os-win32.h"
> #endif

Wait, so your mingw toolchain doesn't define _WIN32 ??
That seems likely to break a lot of other code that does
ifdef checks on _WIN32.

-- PMM

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 27 Nov 2014, at 21:34, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 27 November 2014 at 16:43, Liviu Ionescu <ilg@livius.net> wrote:
>> in qemu-common.h:
>> 
>> #ifdef _WIN32
>> #include "sysemu/os-win32.h"
>> #endif
>> 
>> #ifdef __MINGW32__
>> #include "sysemu/os-win32.h"
>> #endif
> 
> Wait, so your mingw toolchain doesn't define _WIN32 ??
> That seems likely to break a lot of other code that does
> ifdef checks on _WIN32.

good point! 

I removed the second #ifdef, and the build passed.

but the countless warnings are still there :-(


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 27.11.2014 um 20:57 schrieb Liviu Ionescu:
> 
> On 27 Nov 2014, at 21:34, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> On 27 November 2014 at 16:43, Liviu Ionescu <ilg@livius.net> wrote:
>>> in qemu-common.h:
>>>
>>> #ifdef _WIN32
>>> #include "sysemu/os-win32.h"
>>> #endif
>>>
>>> #ifdef __MINGW32__
>>> #include "sysemu/os-win32.h"
>>> #endif
>>
>> Wait, so your mingw toolchain doesn't define _WIN32 ??
>> That seems likely to break a lot of other code that does
>> ifdef checks on _WIN32.
> 
> good point! 
> 
> I removed the second #ifdef, and the build passed.
> 
> but the countless warnings are still there :-(
> 
> 
> regards,
> 
> Liviu


The countless warnings are "normal" because you use MinGW which is
unmaintained since several years.

There is a better alternative: use Mingw-w64. It compiles QEMU (*nearly)
without warnings, solves the ffs problem and has the additional benefit
that it supports both 32 bit and 64 bit builds.

Maybe we should drop MinGW support completely...

Cheers
Stefan

*nearly means that there are still warnings for format strings in C++
code. You won't see them if you don't install a C++ compiler, but as you
are interested in ARM and the C++ code is needed for the ARM
disassembler, you might want it.

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 27 Nov 2014, at 22:09, Stefan Weil <sw@weilnetz.de> wrote:

> There is a better alternative: use Mingw-w64.

working on it.

> Maybe we should drop MinGW support completely...

ok, as soon as we fix the build details on MinGW-w64, I'll remove the MinGW instructions from my wiki.


Liviu

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 27 November 2014 at 20:09, Stefan Weil <sw@weilnetz.de> wrote:
> *nearly means that there are still warnings for format strings in C++
> code.

Hmm, do we still have these with the libvixl version we have
now? If so, could you forward me a copy of them and I'll see
if I can persuade upstream to fix them...

thanks
-- PMM

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 27 Nov 2014, at 22:18, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 27 November 2014 at 20:09, Stefan Weil <sw@weilnetz.de> wrote:
>> *nearly means that there are still warnings for format strings in C++
>> code.
> 
> Hmm, do we still have these with the libvixl version we have
> now? If so, could you forward me a copy of them and I'll see
> if I can persuade upstream to fix them...

if you are interested, three small warnings when building QEMU on OS X:

...
  CXX   disas/arm-a64.o
In file included from /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/disas/arm-a64.cc:23:
In file included from /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/include/disas/bfd.h:12:
In file included from /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/include/qemu-common.h:44:
In file included from /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/include/qemu/option.h:31:
In file included from /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/include/qapi/error.h:16:
./qapi-types.h:3727:1: warning: empty struct has size 0 in C, size 1 in C++ [-Wextern-c-compat]
struct Abort
^
./qapi-types.h:3786:1: warning: empty struct has size 0 in C, size 1 in C++ [-Wextern-c-compat]
struct NetdevNoneOptions
^
./qapi-types.h:4257:1: warning: empty struct has size 0 in C, size 1 in C++ [-Wextern-c-compat]
struct ChardevDummy
^
3 warnings generated.
  CC    disas/i386.o
...


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 27 November 2014 at 20:27, Liviu Ionescu <ilg@livius.net> wrote:
> if you are interested, three small warnings when building QEMU on OS X:

I build on OSX fairly often; because it's using clang it still
has a bunch of warnings which happen because clang reports a
different set of things to gcc. I'm hoping we'll be able to
fix these for 2.3.

-- PMM

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 28 Nov 2014, at 00:04, Peter Maydell <peter.maydell@linaro.org> wrote:

> ... OSX ... clang ... a bunch of warnings ... I'm hoping we'll be able to
> fix these for 2.3.

ok, thank you,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 27.11.2014 um 21:18 schrieb Peter Maydell:
> On 27 November 2014 at 20:09, Stefan Weil <sw@weilnetz.de> wrote:
>> *nearly means that there are still warnings for format strings in C++
>> code.
> 
> Hmm, do we still have these with the libvixl version we have
> now? If so, could you forward me a copy of them and I'll see
> if I can persuade upstream to fix them...
> 
> thanks
> -- PMM
> 


The libvixl code is correct, but the C++ compiler would need to be
fixed. Here are some examples:

disas/libvixl/a64/disasm-a64.cc:1340:57: warning: unknown conversion
type character ‘l’ in format [-Wformat]
disas/libvixl/a64/disasm-a64.cc:1340:57: warning: too many arguments for
format [-Wformat-extra-args]
disas/libvixl/a64/disasm-a64.cc:1492:42: warning: unknown conversion
type character ‘l’ in format [-Wformat]

That code uses PRIx64, so the format specifier is %llx which is correct.
Obviously the C++ compiler ignores that QEMU uses ANSI format specifiers
(compiler option -D__USE_MINGW_ANSI_STDIO=1) instead of the MS specific
ones.

A simple workaround for QEMU would just suppress -Wformat and
-Wformat-extra-args for C++ code.

Regards
Stefan

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 28 November 2014 at 07:14, Stefan Weil <sw@weilnetz.de> wrote:
> The libvixl code is correct, but the C++ compiler would need to be
> fixed. Here are some examples:
>
> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: unknown conversion
> type character ‘l’ in format [-Wformat]
> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: too many arguments for
> format [-Wformat-extra-args]
> disas/libvixl/a64/disasm-a64.cc:1492:42: warning: unknown conversion
> type character ‘l’ in format [-Wformat]
>
> That code uses PRIx64, so the format specifier is %llx which is correct.
> Obviously the C++ compiler ignores that QEMU uses ANSI format specifiers
> (compiler option -D__USE_MINGW_ANSI_STDIO=1) instead of the MS specific
> ones.

Lovely.

> A simple workaround for QEMU would just suppress -Wformat and
> -Wformat-extra-args for C++ code.

I'd prefer not to lose those (just because once you turn off a
warning it's never going to come back, practically speaking).
We could have a configure test that checked whether the c++
compiler understood %llx, maybe?

-- PMM

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 28 November 2014 at 07:14, Stefan Weil <sw@weilnetz.de> wrote:
> The libvixl code is correct, but the C++ compiler would need to be
> fixed. Here are some examples:
>
> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: unknown conversion
> type character ‘l’ in format [-Wformat]
> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: too many arguments for
> format [-Wformat-extra-args]
> disas/libvixl/a64/disasm-a64.cc:1492:42: warning: unknown conversion
> type character ‘l’ in format [-Wformat]
>
> That code uses PRIx64, so the format specifier is %llx which is correct.
> Obviously the C++ compiler ignores that QEMU uses ANSI format specifiers
> (compiler option -D__USE_MINGW_ANSI_STDIO=1) instead of the MS specific
> ones.

I finally got around to looking at this (a year later!), and it turns out
that the problem here is just that libvixl's code for marking functions
as having format strings doesn't have the check that we do in
include/qemu/compiler.h:

#if defined __GNUC__
# if !QEMU_GNUC_PREREQ(4, 4)
   /* gcc versions before 4.4.x don't support gnu_printf, so use printf. */
#  define GCC_FMT_ATTR(n, m) __attribute__((format(printf, n, m)))
# else
   /* Use gnu_printf when supported (qemu uses standard format strings). */
#  define GCC_FMT_ATTR(n, m) __attribute__((format(gnu_printf, n, m)))
#  if defined(_WIN32)
    /* Map __printf__ to __gnu_printf__ because we want standard format strings
     * even when MinGW or GLib include files use __printf__. */
#   define __printf__ __gnu_printf__
#  endif
# endif
#else
#define GCC_FMT_ATTR(n, m)
#endif

...which will effectively cause us to use 'gnu_printf' on this
compiler, which works. The libvixl headers always use plain 'printf',
which gets warnings. So I think we can fix this pretty simply in
disas/libvixl/utils.h by making it also do "use gnu_printf for
a compiler that's 4.4 or better".

thanks
-- PMM

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 27.11.2015 um 19:49 schrieb Peter Maydell:
> On 28 November 2014 at 07:14, Stefan Weil <sw@weilnetz.de> wrote:
>> The libvixl code is correct, but the C++ compiler would need to be
>> fixed. Here are some examples:
>>
>> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: unknown conversion
>> type character ‘l’ in format [-Wformat]
>> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: too many arguments for
>> format [-Wformat-extra-args]
>> disas/libvixl/a64/disasm-a64.cc:1492:42: warning: unknown conversion
>> type character ‘l’ in format [-Wformat]
>>
>> That code uses PRIx64, so the format specifier is %llx which is correct.
>> Obviously the C++ compiler ignores that QEMU uses ANSI format specifiers
>> (compiler option -D__USE_MINGW_ANSI_STDIO=1) instead of the MS specific
>> ones.
> 
> I finally got around to looking at this (a year later!), and it turns out
> that the problem here is just that libvixl's code for marking functions
> as having format strings doesn't have the check that we do in
> include/qemu/compiler.h:
> 
> #if defined __GNUC__
> # if !QEMU_GNUC_PREREQ(4, 4)
>    /* gcc versions before 4.4.x don't support gnu_printf, so use printf. */
> #  define GCC_FMT_ATTR(n, m) __attribute__((format(printf, n, m)))
> # else
>    /* Use gnu_printf when supported (qemu uses standard format strings). */
> #  define GCC_FMT_ATTR(n, m) __attribute__((format(gnu_printf, n, m)))
> #  if defined(_WIN32)
>     /* Map __printf__ to __gnu_printf__ because we want standard format strings
>      * even when MinGW or GLib include files use __printf__. */
> #   define __printf__ __gnu_printf__
> #  endif
> # endif
> #else
> #define GCC_FMT_ATTR(n, m)
> #endif
> 
> ...which will effectively cause us to use 'gnu_printf' on this
> compiler, which works. The libvixl headers always use plain 'printf',
> which gets warnings. So I think we can fix this pretty simply in
> disas/libvixl/utils.h by making it also do "use gnu_printf for
> a compiler that's 4.4 or better".
> 
> thanks
> -- PMM
> 

Yes, that's correct. I just did a short test and replaced "printf"
by "gnu_printf" in disas/libvixl/utils.h: no more warnings when MinGW
compiles disas/libvixl/a64/disasm-a64.cc.

I think we can wait for a new version of libvixl which includes the fix,
no need for a last minute fix for QEMU 2.5. Will you report it to the
libvixl developers?

Thanks,
Stefan

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 27 November 2015 at 19:16, Stefan Weil <sw@weilnetz.de> wrote:
> Yes, that's correct. I just did a short test and replaced "printf"
> by "gnu_printf" in disas/libvixl/utils.h: no more warnings when MinGW
> compiles disas/libvixl/a64/disasm-a64.cc.
>
> I think we can wait for a new version of libvixl which includes the fix,
> no need for a last minute fix for QEMU 2.5. Will you report it to the
> libvixl developers?

Yes, I've reported it to them, and I agree we don't need to fix
this for 2.5. (There are other warnings with this mingw compiler
anyway.)

thanks
-- PMM

Re: [Qemu-devel] MinGW build

[Juan Quintela]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On 27 November 2015 at 19:16, Stefan Weil <sw@weilnetz.de> wrote:
>> Yes, that's correct. I just did a short test and replaced "printf"
>> by "gnu_printf" in disas/libvixl/utils.h: no more warnings when MinGW
>> compiles disas/libvixl/a64/disasm-a64.cc.
>>
>> I think we can wait for a new version of libvixl which includes the fix,
>> no need for a last minute fix for QEMU 2.5. Will you report it to the
>> libvixl developers?
>
> Yes, I've reported it to them, and I agree we don't need to fix
> this for 2.5. (There are other warnings with this mingw compiler
> anyway.)

For my compiler (F23 cross-compiler) and a fairly large configuration (*)
this is the only warning.  I will test later if this fix for me.

Later, Juan.

(*): fairly large: Everything that I was able to get libraries from
     Fedora without having to cross-compile anything by hand.

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 29 November 2015 at 12:03, Juan Quintela <quintela@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> wrote:
>> Yes, I've reported it to them, and I agree we don't need to fix
>> this for 2.5. (There are other warnings with this mingw compiler
>> anyway.)
>
> For my compiler (F23 cross-compiler) and a fairly large configuration (*)
> this is the only warning.

The others I see are:

  CC    qga/commands.o
In file included from
/home/petmay01/linaro/mingw64/lib/glib-2.0/include/glibconfig.h:9:0,
                 from
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gtypes.h:34,
                 from
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/galloca.h:34,
                 from /home/petmay01/linaro/mingw64/include/glib-2.0/glib.h:32,
                 from /home/petmay01/linaro/qemu-for-merges/qga/commands.c:13:
/home/petmay01/linaro/qemu-for-merges/qga/commands.c: In function
‘qmp_guest_exec_status’:
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:53:
error: typedef ‘_GStaticAssertCompileTimeAssertion_0’ locally defined
but not used [-Werror=unused-local-typedefs]
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE
(_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
                                                     ^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:159:47:
note: in definition of macro ‘G_PASTE_ARGS’
 #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
                                               ^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:44:
note: in expansion of macro ‘G_PASTE’
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE
(_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
                                            ^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gatomic.h:79:5:
note: in expansion of macro ‘G_STATIC_ASSERT’
     G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint));                     \
     ^
/home/petmay01/linaro/qemu-for-merges/qga/commands.c:157:21: note: in
expansion of macro ‘g_atomic_int_get’
     bool finished = g_atomic_int_get(&gei->finished);
                     ^

(and similar others in this file).

thanks
-- PMM

Re: [Qemu-devel] MinGW build

[Peter Maydell]

On 3 December 2015 at 11:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 29 November 2015 at 12:03, Juan Quintela <quintela@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>> Yes, I've reported it to them, and I agree we don't need to fix
>>> this for 2.5. (There are other warnings with this mingw compiler
>>> anyway.)
>>
>> For my compiler (F23 cross-compiler) and a fairly large configuration (*)
>> this is the only warning.
>
> The others I see are:
>
>   CC    qga/commands.o
> In file included from
> /home/petmay01/linaro/mingw64/lib/glib-2.0/include/glibconfig.h:9:0,
>                  from
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gtypes.h:34,
>                  from
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/galloca.h:34,
>                  from /home/petmay01/linaro/mingw64/include/glib-2.0/glib.h:32,
>                  from /home/petmay01/linaro/qemu-for-merges/qga/commands.c:13:
> /home/petmay01/linaro/qemu-for-merges/qga/commands.c: In function
> ‘qmp_guest_exec_status’:
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:53:
> error: typedef ‘_GStaticAssertCompileTimeAssertion_0’ locally defined
> but not used [-Werror=unused-local-typedefs]
>  #define G_STATIC_ASSERT(expr) typedef char G_PASTE
> (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
>                                                      ^
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:159:47:
> note: in definition of macro ‘G_PASTE_ARGS’
>  #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
>                                                ^
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:44:
> note: in expansion of macro ‘G_PASTE’
>  #define G_STATIC_ASSERT(expr) typedef char G_PASTE
> (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
>                                             ^
> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gatomic.h:79:5:
> note: in expansion of macro ‘G_STATIC_ASSERT’
>      G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint));                     \
>      ^
> /home/petmay01/linaro/qemu-for-merges/qga/commands.c:157:21: note: in
> expansion of macro ‘g_atomic_int_get’
>      bool finished = g_atomic_int_get(&gei->finished);
>                      ^

It looks like these were fixed in glib upstream:
https://git.gnome.org/browse/glib/commit/?id=0ea7abaed5
(I'm using glib 2.34.3-1, which doesn't have the fix.)

thanks
-- PMM

Re: [Qemu-devel] MinGW build

[Juan Quintela]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On 3 December 2015 at 11:58, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 29 November 2015 at 12:03, Juan Quintela <quintela@redhat.com> wrote:
>>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> Yes, I've reported it to them, and I agree we don't need to fix
>>>> this for 2.5. (There are other warnings with this mingw compiler
>>>> anyway.)
>>>
>>> For my compiler (F23 cross-compiler) and a fairly large configuration (*)
>>> this is the only warning.
>>
>> The others I see are:
>>
>>   CC    qga/commands.o
>> In file included from
>> /home/petmay01/linaro/mingw64/lib/glib-2.0/include/glibconfig.h:9:0,
>>                  from
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gtypes.h:34,
>>                  from
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/galloca.h:34,
>>                  from /home/petmay01/linaro/mingw64/include/glib-2.0/glib.h:32,
>>                  from /home/petmay01/linaro/qemu-for-merges/qga/commands.c:13:
>> /home/petmay01/linaro/qemu-for-merges/qga/commands.c: In function
>> ‘qmp_guest_exec_status’:
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:53:
>> error: typedef ‘_GStaticAssertCompileTimeAssertion_0’ locally defined
>> but not used [-Werror=unused-local-typedefs]
>>  #define G_STATIC_ASSERT(expr) typedef char G_PASTE
>> (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
>>                                                      ^
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:159:47:
>> note: in definition of macro ‘G_PASTE_ARGS’
>>  #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
>>                                                ^
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:44:
>> note: in expansion of macro ‘G_PASTE’
>>  #define G_STATIC_ASSERT(expr) typedef char G_PASTE
>> (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
>>                                             ^
>> /home/petmay01/linaro/mingw64/include/glib-2.0/glib/gatomic.h:79:5:
>> note: in expansion of macro ‘G_STATIC_ASSERT’
>>      G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint));                     \
>>      ^
>> /home/petmay01/linaro/qemu-for-merges/qga/commands.c:157:21: note: in
>> expansion of macro ‘g_atomic_int_get’
>>      bool finished = g_atomic_int_get(&gei->finished);
>>                      ^
>
> It looks like these were fixed in glib upstream:
> https://git.gnome.org/browse/glib/commit/?id=0ea7abaed5
> (I'm using glib 2.34.3-1, which doesn't have the fix.)
>
> thanks

Yeap, my glib lib is 2.46.1.

mingw32-glib2-2.46.1-1.fc23.noarch

#livinginthebleedingedge O:-)

Thanks, Juan.

Re: [Qemu-devel] MinGW build

[Juan Quintela]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On 28 November 2014 at 07:14, Stefan Weil <sw@weilnetz.de> wrote:
>> The libvixl code is correct, but the C++ compiler would need to be
>> fixed. Here are some examples:
>>
>> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: unknown conversion
>> type character ‘l’ in format [-Wformat]
>> disas/libvixl/a64/disasm-a64.cc:1340:57: warning: too many arguments for
>> format [-Wformat-extra-args]
>> disas/libvixl/a64/disasm-a64.cc:1492:42: warning: unknown conversion
>> type character ‘l’ in format [-Wformat]
>>
>> That code uses PRIx64, so the format specifier is %llx which is correct.
>> Obviously the C++ compiler ignores that QEMU uses ANSI format specifiers
>> (compiler option -D__USE_MINGW_ANSI_STDIO=1) instead of the MS specific
>> ones.
>
> I finally got around to looking at this (a year later!), and it turns out
> that the problem here is just that libvixl's code for marking functions
> as having format strings doesn't have the check that we do in
> include/qemu/compiler.h:
>
> #if defined __GNUC__
> # if !QEMU_GNUC_PREREQ(4, 4)
>    /* gcc versions before 4.4.x don't support gnu_printf, so use printf. */
> #  define GCC_FMT_ATTR(n, m) __attribute__((format(printf, n, m)))
> # else
>    /* Use gnu_printf when supported (qemu uses standard format strings). */
> #  define GCC_FMT_ATTR(n, m) __attribute__((format(gnu_printf, n, m)))
> #  if defined(_WIN32)
>     /* Map __printf__ to __gnu_printf__ because we want standard format strings
>      * even when MinGW or GLib include files use __printf__. */
> #   define __printf__ __gnu_printf__
> #  endif
> # endif
> #else
> #define GCC_FMT_ATTR(n, m)
> #endif
>
> ...which will effectively cause us to use 'gnu_printf' on this
> compiler, which works. The libvixl headers always use plain 'printf',
> which gets warnings. So I think we can fix this pretty simply in
> disas/libvixl/utils.h by making it also do "use gnu_printf for
> a compiler that's 4.4 or better".

Confirmed that following patch works for me (as I don't have a pre-4.4
compiler, I didn't care if doing the proper thing).

diff --git a/disas/libvixl/utils.h b/disas/libvixl/utils.h
index b440626..96ef4b0 100644
--- a/disas/libvixl/utils.h
+++ b/disas/libvixl/utils.h
@@ -36,7 +36,7 @@ namespace vixl {
 // Macros for compile-time format checking.
 #if defined(__GNUC__)
 #define PRINTF_CHECK(format_index, varargs_index) \
-  __attribute__((format(printf, format_index, varargs_index)))
+  __attribute__((format(gnu_printf, format_index, varargs_index)))
 #else
 #define PRINTF_CHECK(format_index, varargs_index)
 #endif

I lied, on win64, you also need the following one (notice that
getpagesize on unix return int as far as I can see).  And this is the
solution that was suggested on list.  Should I submit that one, or
should we leave the warning?

Thanks, Juan.


diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
index 13dcef6..400e098 100644
--- a/include/sysemu/os-win32.h
+++ b/include/sysemu/os-win32.h
@@ -87,7 +87,7 @@ static inline void os_setup_post(void) {}
 void os_set_line_buffering(void);
 static inline void os_set_proc_name(const char *dummy) {}

-size_t getpagesize(void);
+int getpagesize(void);

 #if !defined(EPROTONOSUPPORT)
 # define EPROTONOSUPPORT EINVAL
diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index 09f9e98..7aad185 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -454,7 +454,7 @@ gint g_poll(GPollFD *fds, guint nfds, gint timeout)
     return retval;
 }

-size_t getpagesize(void)
+getpagesize(void)
 {
     SYSTEM_INFO system_info;

@@ -465,7 +465,7 @@ size_t getpagesize(void)
 void os_mem_prealloc(int fd, char *area, size_t memory)
 {
     int i;
-    size_t pagesize = getpagesize();
+    int pagesize = getpagesize();

     memory = (memory + pagesize - 1) & -pagesize;
     for (i = 0; i < memory / pagesize; i++) {

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 30.11.2015 um 14:24 schrieb Juan Quintela:

[...]
> I lied, on win64, you also need the following one (notice that
> getpagesize on unix return int as far as I can see).  And this is the
> solution that was suggested on list.  Should I submit that one, or
> should we leave the warning?
>
> Thanks, Juan.
>
>
> diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
> index 13dcef6..400e098 100644
> --- a/include/sysemu/os-win32.h
> +++ b/include/sysemu/os-win32.h
> @@ -87,7 +87,7 @@ static inline void os_setup_post(void) {}
>  void os_set_line_buffering(void);
>  static inline void os_set_proc_name(const char *dummy) {}
>
> -size_t getpagesize(void);
> +int getpagesize(void);
>
>  #if !defined(EPROTONOSUPPORT)
>  # define EPROTONOSUPPORT EINVAL
> diff --git a/util/oslib-win32.c b/util/oslib-win32.c
> index 09f9e98..7aad185 100644
> --- a/util/oslib-win32.c
> +++ b/util/oslib-win32.c
> @@ -454,7 +454,7 @@ gint g_poll(GPollFD *fds, guint nfds, gint timeout)
>      return retval;
>  }
>
> -size_t getpagesize(void)
> +getpagesize(void)
>  {
>      SYSTEM_INFO system_info;
>
> @@ -465,7 +465,7 @@ size_t getpagesize(void)
>  void os_mem_prealloc(int fd, char *area, size_t memory)
>  {
>      int i;
> -    size_t pagesize = getpagesize();
> +    int pagesize = getpagesize();
>
>      memory = (memory + pagesize - 1) & -pagesize;
>      for (i = 0; i < memory / pagesize; i++) {


Something like this one: http://patchwork.ozlabs.org/patch/549870/ ? :-)

I'd be happy if you could review all three commits in that pull request,
because nobody did so far.

Regards,
Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 27 Nov 2014, at 22:09, Stefan Weil <sw@weilnetz.de> wrote:

> ... use Mingw-w64. It compiles QEMU ...

one of my requirements for a Windows version of QEMU is to be statically linked, and do not depend on third party libraries that are not present in a common Windows installation.

do you have a build procedure with Mingw-w64 that creates a static program? what libraries are needed, where do you get them or how do you build them as static libraries?


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 27.11.2014 um 21:52 schrieb Liviu Ionescu:
> 
> On 27 Nov 2014, at 22:09, Stefan Weil <sw@weilnetz.de> wrote:
> 
>> ... use Mingw-w64. It compiles QEMU ...
> 
> one of my requirements for a Windows version of QEMU is to be statically linked, and do not depend on third party libraries that are not present in a common Windows installation.


Do you really need statically linked executables (they might need a lot
of disk space if you install all of them), or is it sufficient to
distribute all third party libraries which are needed to run QEMU
together with the executables (as I do it with my installers for Windows
on http://qemu.weilnetz.de/)? Even with a statically linked executable,
you won't get a one-file-distribution because QEMU needs a lot of
additional files during runtime (keyboard maps, firmware images, ...).

> 
> do you have a build procedure with Mingw-w64 that creates a static program? what libraries are needed, where do you get them or how do you build them as static libraries?

Up to now, I never have build a static QEMU executable for Windows, so I
simply don't know which problems might occur and which libraries are
available for static linking or not.

Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 27 Nov 2014, at 23:14, Stefan Weil <sw@weilnetz.de> wrote:

> Do you really need statically linked executables

actually I don't know, my experience with Windows is limited :-(

on OS X, if I distribute a folder containing an executable and a bunch of dynamic libraries, the folder where the executable is located is the first choice for searching the libraries, so I don't have to mess with library versions in any system library folders.

on Windows I could not make this work. if this is possible, and you have a procedure to create a setup that does a reasonable job without messing other things, ok, I don't mind packing an executable and several dynamic libraries, I'll use it too.


regards,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 27.11.2014 um 22:38 schrieb Liviu Ionescu:
> 
> On 27 Nov 2014, at 23:14, Stefan Weil <sw@weilnetz.de> wrote:
> 
>> Do you really need statically linked executables
> 
> actually I don't know, my experience with Windows is limited :-(
> 
> on OS X, if I distribute a folder containing an executable and a bunch of dynamic libraries, the folder where the executable is located is the first choice for searching the libraries, so I don't have to mess with library versions in any system library folders.
> 
> on Windows I could not make this work. if this is possible, and you have a procedure to create a setup that does a reasonable job without messing other things, ok, I don't mind packing an executable and several dynamic libraries, I'll use it too.

Windows dynamic libraries (DLL files) are also loaded from the
executable's directory if they exist there. You don't need a special
setup to make that work, it's the standard behaviour.

Regards
Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 28 Nov 2014, at 08:20, Stefan Weil <sw@weilnetz.de> wrote:

> Windows dynamic libraries (DLL files) are also loaded from the
> executable's directory if they exist there. You don't need a special
> setup to make that work, it's the standard behaviour.

ok, great! could you send me your build procedure? (and prerequisites).


thank you,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 28.11.2014 um 07:23 schrieb Liviu Ionescu:
> 
> On 28 Nov 2014, at 08:20, Stefan Weil <sw@weilnetz.de> wrote:
> 
>> Windows dynamic libraries (DLL files) are also loaded from the
>> executable's directory if they exist there. You don't need a special
>> setup to make that work, it's the standard behaviour.
> 
> ok, great! could you send me your build procedure? (and prerequisites).
> 
> 
> thank you,
> 
> Liviu


This is my build script:
http://qemu.weilnetz.de/results/make-installers-all.

The results of my latest build are here:
http://qemu.weilnetz.de/results/build-20141126.txt.

And here are the dll files which are added to the installers:

$ ls dll/w??
dll/w32:
freetype6.dll     libfontconfig-1.dll      libglib-2.0-0.dll
libpango-1.0-0.dll       libssp-0.dll
intl.dll          libgcc_s_sjlj-1.dll      libgmodule-2.0-0.dll
libpangocairo-1.0-0.dll  libstdc++-6.dll
libatk-1.0-0.dll  libgdk_pixbuf-2.0-0.dll  libgobject-2.0-0.dll
libpangoft2-1.0-0.dll    pdcurses.dll
libcairo-2.dll    libgdk-win32-2.0-0.dll   libgthread-2.0-0.dll
libpangowin32-1.0-0.dll  SDL.dll
libexpat-1.dll    libgio-2.0-0.dll         libgtk-win32-2.0-0.dll
libpng14-14.dll          zlib1.dll

dll/w64:
libatk-1.0-0.dll        libgcc_s_sjlj-1.dll      libgobject-2.0-0.dll
libpango-1.0-0.dll       libssp-0.dll
libcairo-2.dll          libgdk-3-0.dll           libgtk-3-0.dll
libpangocairo-1.0-0.dll  libstdc++-6.dll
libcairo-gobject-2.dll  libgdk_pixbuf-2.0-0.dll  libiconv-2.dll
libpangoft2-1.0-0.dll    libxml2-2.dll
libffi-6.dll            libgio-2.0-0.dll         libintl-8.dll
libpangowin32-1.0-0.dll  SDL.dll
libfontconfig-1.dll     libglib-2.0-0.dll        libjpeg-9.dll
libpixman-1-0.dll        zlib1.dll
libfreetype-6.dll       libgmodule-2.0-0.dll     liblzma-5.dll
libpng15-15.dll

Please note that this is a cross build running on Debian GNU Linux, so
configure will be called differently for a native build.

You'll need NSIS if you want to build the installer. If you want to sign
your executables, you also need a script which does that.

Regards
Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 28 Nov 2014, at 09:03, Stefan Weil <sw@weilnetz.de> wrote:

> This is my build script:
> http://qemu.weilnetz.de/results/make-installers-all.

we finally have a functional windows version, installed with a setup, as you recommended.

the build procedure was fully documented at:

http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU

(as Windows cross build on Debian)


the build procedure itself is moderately complex, but fixing the prerequisite details was nightmarish, the official wiki page is schematic, at least.

not to mention the note that only older versions of glib are supported, hidden somewhere. perhaps an update to newer glib would be useful.

other details worth noting were related to the lack of clear separation between the host build and the cross build.

the procedure to detect the presence of packages with pkg-config is great, but is seems not used consistently, for example detecting libz is not done with pkg-config, but using the compiler, and this required some extra flags to configure.

to accomodate the details of my windows setup, I also had to add a new QEMU_NSI_FILE variable to Makefile, so I can redefine it externally.

 
regards,

Liviu

Re: [Qemu-devel] MinGW build

[Stefan Weil]

Am 01.12.2014 um 11:30 schrieb Liviu Ionescu:
> 
> On 28 Nov 2014, at 09:03, Stefan Weil <sw@weilnetz.de> wrote:
> 
>> This is my build script:
>> http://qemu.weilnetz.de/results/make-installers-all.
> 
> we finally have a functional windows version, installed with a setup, as you recommended.
> 
> the build procedure was fully documented at:
> 
> http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU
> 
> (as Windows cross build on Debian)
> 
> 
> the build procedure itself is moderately complex, but fixing the prerequisite details was nightmarish, the official wiki page is schematic, at least.
> 
> not to mention the note that only older versions of glib are supported, hidden somewhere. perhaps an update to newer glib would be useful.
> 
> other details worth noting were related to the lack of clear separation between the host build and the cross build.
> 
> the procedure to detect the presence of packages with pkg-config is great, but is seems not used consistently, for example detecting libz is not done with pkg-config, but using the compiler, and this required some extra flags to configure.
> 
> to accomodate the details of my windows setup, I also had to add a new QEMU_NSI_FILE variable to Makefile, so I can redefine it externally.
> 
>  
> regards,
> 
> Liviu
> 

Hi,

thank's for your work on this documention.

Here are some more hints which might help people to get cross
compilation for Windows running. http://qemu.weilnetz.de/debian/
includes some packages which I made from the GTK all-in-one bundles and
also packages for libfdt which I compiled from the sources.

Regards
Stefan

Re: [Qemu-devel] MinGW build

[Liviu Ionescu]

On 01 Dec 2014, at 20:42, Stefan Weil <sw@weilnetz.de> wrote:

> Here are some more hints which might help people to get cross
> compilation for Windows running. http://qemu.weilnetz.de/debian/
> includes some packages which I made from the GTK all-in-one bundles and
> also packages for libfdt which I compiled from the sources.

unfortunately my mind is not that sharp to get the hints, I saw just a list of packages, without any explanations on why I should use them. :-(

I think the same problem applies to the existing so called 'documentation', which is not only out of date, but very cryptic, and very less procedural.

as you could see, my style of documentation, even when intended for my own use, should allow anyone, regardless of any specific project experience, to complete the tasks by simply following the instructions with copy/paste.

---

in addition to the problems noted in the previous message (regarding the old glib, the imprecise configure behaviour when running with cross builds), I noticed another problem:

it looks like the the MinGW-w64 toolchains that come with Debian are configured with '--enable-sjlj-exceptions', which is the old way of processing exception, while the MinGW (32) toolchain is configured with '--disable-sjlj-exceptions --with-dwarf2', which is the modern way of processing exceptions.

I don't know if this has any impact on your project, but I would say that the MinGW-w64 project is not configured right, and needs extra care when using (special sjlj DLLs).


regards,

Liviu