Peter Maydell wrote:
> On 3 December 2015 at 11:58, Peter Maydell wrote:
>> On 29 November 2015 at 12:03, Juan Quintela wrote:
>>> Peter Maydell 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
On 3 December 2015 at 11:58, Peter Maydell wrote:
> On 29 November 2015 at 12:03, Juan Quintela wrote:
>> Peter Maydell 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 compil
On 29 November 2015 at 12:03, Juan Quintela wrote:
> Peter Maydell 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 (*
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?
>
> Thank
Peter Maydell wrote:
> On 28 November 2014 at 07:14, Stefan Weil 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]
>>
Peter Maydell wrote:
> On 27 November 2015 at 19:16, Stefan Weil 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 v
On 27 November 2015 at 19:16, Stefan Weil 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 inclu
Am 27.11.2015 um 19:49 schrieb Peter Maydell:
> On 28 November 2014 at 07:14, Stefan Weil 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’
On 28 November 2014 at 07:14, Stefan Weil 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.c
On 01 Dec 2014, at 20:42, Stefan Weil 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 fr
Am 01.12.2014 um 11:30 schrieb Liviu Ionescu:
>
> On 28 Nov 2014, at 09:03, Stefan Weil 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 pr
On 28 Nov 2014, at 09:03, Stefan Weil 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.ne
On 28 November 2014 at 07:14, Stefan Weil 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.c
Am 27.11.2014 um 21:18 schrieb Peter Maydell:
> On 27 November 2014 at 20:09, Stefan Weil 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
Am 28.11.2014 um 07:23 schrieb Liviu Ionescu:
>
> On 28 Nov 2014, at 08:20, Stefan Weil 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.
>
>
On 28 Nov 2014, at 08:20, Stefan Weil 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 pr
Am 27.11.2014 um 22:38 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 23:14, Stefan Weil 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 o
On 28 Nov 2014, at 00:04, Peter Maydell wrote:
> ... OSX ... clang ... a bunch of warnings ... I'm hoping we'll be able to
> fix these for 2.3.
ok, thank you,
Liviu
On 27 November 2014 at 20:27, Liviu Ionescu 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
On 27 Nov 2014, at 23:14, Stefan Weil 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 loca
Am 27.11.2014 um 21:52 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 22:09, Stefan Weil 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
On 27 Nov 2014, at 22:09, Stefan Weil 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 proced
On 27 Nov 2014, at 22:18, Peter Maydell wrote:
> On 27 November 2014 at 20:09, Stefan Weil 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
On 27 November 2014 at 20:09, Stefan Weil 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...
tha
On 27 Nov 2014, at 22:09, Stefan Weil 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
Am 27.11.2014 um 20:57 schrieb Liviu Ionescu:
>
> On 27 Nov 2014, at 21:34, Peter Maydell wrote:
>
>> On 27 November 2014 at 16:43, Liviu Ionescu wrote:
>>> in qemu-common.h:
>>>
>>> #ifdef _WIN32
>>> #include "sysemu/os-win32.h"
>>> #endif
>>>
>>> #ifdef __MINGW32__
>>> #include "sysemu/os-win
On 27 Nov 2014, at 21:34, Peter Maydell wrote:
> On 27 November 2014 at 16:43, Liviu Ionescu 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
On 27 November 2014 at 16:43, Liviu Ionescu 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 tha
On 26 Nov 2014, at 22:13, Peter Maydell 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
On 26 Nov 2014, at 22:13, Peter Maydell 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
Am 26.11.2014 um 21:13 schrieb Peter Maydell:
> On 26 November 2014 at 19:55, Liviu Ionescu 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
On 26 November 2014 at 19:55, Liviu Ionescu 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
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 ha
Hello,
Building QEMU from the current sources (qemu-snapshot-2005-11-26_23) on
MingW host fails.
The functions "qemu_chr_open_file_out()" and "qemu_chr_open_pipe()" are not
defined for the WIN32 build.
Below is the build log:
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/h
34 matches
Mail list logo
