On 20/07/17 22:09, Peter Maydell wrote:
>> The fix is seemingly quite simple:
>>
>> diff --git a/block/vpc.c b/block/vpc.c
>> index 10e6519..574879b 100644
>> --- a/block/vpc.c
>> +++ b/block/vpc.c
>> @@ -649,7 +649,7 @@ vpc_co_pwritev(BlockDriverState *bs, uint64_t
>> offset, uint64_t bytes,
>>
On 20 July 2017 at 20:29, Mark Cave-Ayland
wrote:
> On 19/07/17 18:09, Mark Cave-Ayland wrote:
>
>> Hi all,
>>
>> I see the following build failure here on git master with gcc 4.7.2:
>>
>> cc -I/home/build/src/qemu/git/qemu/block -Iblock
>> -I/home/build/src/qemu/git/qemu/tcg
>> -I/home/build/src/
On 19/07/17 18:09, Mark Cave-Ayland wrote:
> Hi all,
>
> I see the following build failure here on git master with gcc 4.7.2:
>
> cc -I/home/build/src/qemu/git/qemu/block -Iblock
> -I/home/build/src/qemu/git/qemu/tcg
> -I/home/build/src/qemu/git/qemu/tcg/i386
> -I/home/build/src/qemu/git/qemu/li
Hi all,
I see the following build failure here on git master with gcc 4.7.2:
cc -I/home/build/src/qemu/git/qemu/block -Iblock
-I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I
It seems my source tree wasn't clean. I removed the old tree and that
error is gone.
Thanks,
Jianjun
On 09/19/2016 02:51 PM, John Snow wrote:
>
>
> On 09/19/2016 05:44 PM, Peter Maydell wrote:
>> On 19 September 2016 at 22:38, John Snow wrote:
>>>
>>>
>>> On 09/19/2016 05:17 PM, Jianjun Duan w
make distclean didn't solve the problem.
Thanks,
Jianjun
On 09/19/2016 02:51 PM, John Snow wrote:
>
>
> On 09/19/2016 05:44 PM, Peter Maydell wrote:
>> On 19 September 2016 at 22:38, John Snow wrote:
>>>
>>>
>>> On 09/19/2016 05:17 PM, Jianjun Duan wrote:
Hi,
I ran into the foll
On 09/19/2016 05:44 PM, Peter Maydell wrote:
On 19 September 2016 at 22:38, John Snow wrote:
On 09/19/2016 05:17 PM, Jianjun Duan wrote:
Hi,
I ran into the follow problems when I tried to build code based on
latest master or ppc-for-2.8:
hw/ide/core.c: In function ‘ide_init_ioport’:
hw/i
On 19 September 2016 at 22:38, John Snow wrote:
>
>
> On 09/19/2016 05:17 PM, Jianjun Duan wrote:
>>
>> Hi,
>> I ran into the follow problems when I tried to build code based on
>> latest master or ppc-for-2.8:
>>
>> hw/ide/core.c: In function ‘ide_init_ioport’:
>> hw/ide/core.c:2622:39: error: ‘I
On 09/19/2016 05:17 PM, Jianjun Duan wrote:
Hi,
I ran into the follow problems when I tried to build code based on
latest master or ppc-for-2.8:
hw/ide/core.c: In function ‘ide_init_ioport’:
hw/ide/core.c:2622:39: error: ‘IDEBus’ has no member named ‘portio_list’
isa_register_portio_list(
Hi,
I ran into the follow problems when I tried to build code based on
latest master or ppc-for-2.8:
hw/ide/core.c: In function ‘ide_init_ioport’:
hw/ide/core.c:2622:39: error: ‘IDEBus’ has no member named ‘portio_list’
isa_register_portio_list(dev, &bus->portio_list,
On 21 October 2013 19:22, Ken Moffat wrote:
> I took this to bug-make, but now I'm back here. The first thing in
> rules.mak is
>
> # Don't use implicit rules or variables
> # we have explicit rules for everything
> MAKEFLAGS += -rR
>
> and Paul Smith said -
>
> It's a qemu bug, that just happe
On Sat, Oct 19, 2013 at 10:53:43AM +0100, Ken Moffat wrote:
> On Sat, Oct 19, 2013 at 10:05:10AM +0100, Peter Maydell wrote:
> >
> > Well, the reason would be that nobody in practice will do
> > that. Make should be setting ARFLAGS correctly (as per
> > its documentation) unless you've somehow man
On Sat, Oct 19, 2013 at 10:05:10AM +0100, Peter Maydell wrote:
> On 19 October 2013 00:36, Ken Moffat wrote:
> > Seems I can just
> > $export ARFLAGS="rv"
> > before I configure, and it will build and install. Unless there is
> > some reason NOT to do that, please consider this closed.
>
> Well
On 19 October 2013 00:36, Ken Moffat wrote:
> Seems I can just
> $export ARFLAGS="rv"
> before I configure, and it will build and install. Unless there is
> some reason NOT to do that, please consider this closed.
Well, the reason would be that nobody in practice will do
that. Make should be se
On Fri, Oct 18, 2013 at 11:48:12PM +0100, Ken Moffat wrote:
> ar libfdt/libfdt.a libfdt/fdt.o libfdt/fdt_ro.o libfdt/fdt_wip.o
> libfdt/fdt_sw.o libfdt/fdt_rw.o libfdt/fdt_strerror.o
> ar: two different operation options specified
> Makefile:234: recipe for target 'libfdt/libfdt.a' failed
> make[
Hi,
I'm working through the packages in Beyond Linux From Scratch in
the expectation that make-4.0 would break something. Got about
halfway through and started to doubt that. Then I tried qemu.
Initially 1.6.0, which failed, so tried 1.6.1 and that fails the
same way. Found some comments in
Hi Jesse,
Thanks for looking into this.
On Wed, Feb 27, 2013 at 9:19 AM, Jesse Larrew
wrote:
> Hi David!
>
> On 02/21/2013 05:19 PM, David Holsgrove wrote:
>> Configuring QEMU as
>>
>> ./configure --target-list=i386-softmmu --cpu=i386 --enable-werror
>>
>> results in following error
>>
>> cc1: w
Hi David!
On 02/21/2013 05:19 PM, David Holsgrove wrote:
> Configuring QEMU as
>
> ./configure --target-list=i386-softmmu --cpu=i386 --enable-werror
>
> results in following error
>
> cc1: warnings being treated as errors
> qemu-char.c: In function 'qmp_ringbuf_write':
> qemu-char.c:2764: error
Configuring QEMU as
./configure --target-list=i386-softmmu --cpu=i386 --enable-werror
results in following error
cc1: warnings being treated as errors
qemu-char.c: In function 'qmp_ringbuf_write':
qemu-char.c:2764: error: passing argument 2 of 'g_base64_decode' from
incompatible pointer type
/u
Configuring QEMU as
./configure --target-list=i386-softmmu --cpu=i386 --enable-werror
results in following error
cc1: warnings being treated as errors
qemu-char.c: In function 'qmp_ringbuf_write':
qemu-char.c:2764: error: passing argument 2 of 'g_base64_decode' from
incompatible pointer type
/u
On Tue, Feb 7, 2012 at 9:23 AM, Erik Rull wrote:
>
> On February 6, 2012 at 9:29 AM Stefan Hajnoczi wrote:
>
>> On Thu, Jan 19, 2012 at 08:06:30PM +0100, Erik Rull wrote:
>> > test-coroutine.c:92: warning: implicit declaration of function
>> > 'g_assert_cmpint'
>> ...
>> > erik@debian:~/qemu-test
On February 6, 2012 at 9:29 AM Stefan Hajnoczi wrote:
> On Thu, Jan 19, 2012 at 08:06:30PM +0100, Erik Rull wrote:
> > test-coroutine.c:92: warning: implicit declaration of function
> > 'g_assert_cmpint'
> ...
> > erik@debian:~/qemu-test/qemu-kvm$
>
> This must be an old Debian box. Debian stab
On Thu, Jan 19, 2012 at 08:06:30PM +0100, Erik Rull wrote:
> test-coroutine.c:92: warning: implicit declaration of function
> 'g_assert_cmpint'
...
> erik@debian:~/qemu-test/qemu-kvm$
This must be an old Debian box. Debian stable has a new enough glib
that provides g_assert_cmpint().
The glib te
Hi all,
I just got a copy of the current qemu-kvm but there is a build failure in
test-coroutine.c:
erik@debian:~/qemu-test/qemu-kvm$ make
[...]
CCtest-coroutine.o
test-coroutine.c: In function 'test_nesting':
test-coroutine.c:92: warning: implicit declaration of function
'g_assert_cmpi
On Mon, Nov 14, 2011 at 8:03 AM, Harsh Bora wrote:
> I tried to explore LTTng UST with Qemu and built ust 0.15 (with urcu 0.16 as
> reqd) and observed that Qemu gives compilation errors when built for
> trace-backend = ust. See this:
Hi Harsh,
UST is not a stable library interface. It has not se
Hi,
I tried to explore LTTng UST with Qemu and built ust 0.15 (with urcu
0.16 as reqd) and observed that Qemu gives compilation errors when built
for trace-backend = ust. See this:
[harsh@harshbora v9fs]$ ./configure '--target-list=x86_64-softmmu'
'--enable-debug' '--enable-kvm' --enable-trac
On Wed, Aug 10, 2011 at 9:14 AM, Stefan Hajnoczi
wrote:
> On Tue, Aug 09, 2011 at 05:28:17PM +, Blue Swirl wrote:
>> On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi wrote:
>> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
>> > wrote:
>> >>
>> >>
>> >> LINK qemu-ga
>> >> coroutine-gthr
On Tue, Aug 09, 2011 at 05:28:17PM +, Blue Swirl wrote:
> On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi wrote:
> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
> > wrote:
> >>
> >>
> >> LINK qemu-ga
> >> coroutine-gthread.o: In function `coroutine_init':
> >> /home/opensource/sources
On Tue, 9 Aug 2011 17:28:17 +, Blue Swirl wrote:
> On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi wrote:
> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
> > wrote:
> >>
> >>
> >> LINK qemu-ga
> >> coroutine-gthread.o: In function `coroutine_init':
> >> /home/opensource/sources/qemu/
On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi wrote:
> On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
> wrote:
>>
>>
>> LINK qemu-ga
>> coroutine-gthread.o: In function `coroutine_init':
>> /home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39:
>> undefined reference to `g_th
On Mon, 8 Aug 2011 10:29:04 +0100, Stefan Hajnoczi wrote:
> On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
> wrote:
> >
> >
> > LINK qemu-ga
> > coroutine-gthread.o: In function `coroutine_init':
> > /home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39:
> > undefined reference
On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
wrote:
>
>
> LINK qemu-ga
> coroutine-gthread.o: In function `coroutine_init':
> /home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39: undefined
> reference to `g_thread_init'
> collect2: ld returned 1 exit status
>
> The below pat
LINK qemu-ga
coroutine-gthread.o: In function `coroutine_init':
/home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39: undefined
reference to `g_thread_init'
collect2: ld returned 1 exit status
The below patch fix the failure. I also added the patch in the VirtFS
pull request.
Got this from a qemu-microblaze user:
/opt3/home/jwilliams/petalinux/petalinux-v1.00-
devel/devel/packager/gnu/qemu/qemu-src/hw/virtio-9p.c: In function
???v9fs_setattr_post_chmod???:
/opt3/home/jwilliams/petalinux/petalinux-v1.00-
devel/devel/packager/gnu/qemu/qemu-src/hw/virtio-9p.c:1410: er
* Isaku Yamahata [2010-05-15 17:46:59]:
> Hi.
> Which change set/patches are you using?
> 'make clean; make' doesn't work?
>
Sorry for the noise. 'make defconfig' helped.
Kamalesh
Hi.
Which change set/patches are you using?
'make clean; make' doesn't work?
On Sat, May 15, 2010 at 02:00:00PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> Build fails with following error,
>
> arch_init.o:(.data+0x44): undefined reference to `SB16_init'
> arch_init.o:(.data+0x58): undefined refer
Hi,
Build fails with following error,
arch_init.o:(.data+0x44): undefined reference to `SB16_init'
arch_init.o:(.data+0x58): undefined reference to `ac97_init'
arch_init.o:(.data+0x6c): undefined reference to `es1370_init'
pc.o: In function `pc_init1':
/other/srcs/qemu-kvm/hw/pc.c:1005: undefine
Hi,
just for the record: a build of QEMU from HEAD with
'--enable-io-thread' fails. In "vl.c" "qemu_system_ready" is used but
not declared any longer.
Dirk
Hi folks, I found this problem trying to build qemu from the qemu.git
repo:
03/04 13:07:34 ERROR| kvm:0061| Test failed: Command
failed, rc=2, Command returned non-zero exit status
* Command:
make install
Exit status: 2
Duration: 0
stdout:
install -d -m0755 -p "/usr/local/autotest/te
Sebastian Herbszt schrieb:
> Stefan Weil wrote:
>> Sebastian Herbszt schrieb:
>>> v0.11.0-rc0-1677-gf165b53
>>>
>>> $ ./configure --target-list=i386-softmmu
>>> $ make
>>> Makefile:427: no file name for `-include'
>>> /bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
>>> /bin/s
Sebastian Herbszt wrote:
Stefan Weil wrote:
Sebastian Herbszt schrieb:
v0.11.0-rc0-1677-gf165b53
$ ./configure --target-list=i386-softmmu
$ make
Makefile:427: no file name for `-include'
/bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh.exe: -c: line 2: syntax erro
Stefan Weil wrote:
Sebastian Herbszt schrieb:
v0.11.0-rc0-1677-gf165b53
$ ./configure --target-list=i386-softmmu
$ make
Makefile:427: no file name for `-include'
/bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh.exe: -c: line 2: syntax error: unexpected end of file
Sebastian Herbszt schrieb:
> v0.11.0-rc0-1677-gf165b53
>
> $ ./configure --target-list=i386-softmmu
> $ make
> Makefile:427: no file name for `-include'
> /bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
> /bin/sh.exe: -c: line 2: syntax error: unexpected end of file
> make: *
v0.11.0-rc0-1677-gf165b53
$ ./configure --target-list=i386-softmmu
$ make
Makefile:427: no file name for `-include'
/bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh.exe: -c: line 2: syntax error: unexpected end of file
make: *** [config-all-devices.mak] Error 2
- Se
v0.11.0-rc0-1630-g51cc2e7 fails to build on mingw with gcc version 3.4.5
(mingw32 special)
and GNU Make version 3.79.1.
gcc -I/home/sh/vm/qemu/v0.11.0-rc0-1630-g51cc2e7/slirp -Wold-style-definition
-I.
-I/home/sh/vm/qemu/v0.11.0-rc0-1630-g51cc2e7 -U_FORTIFY_SOURCE -D_GNU_SOURCE
-D_FILE_OFFSET_
On 3/16/08, Peter Volkov <[EMAIL PROTECTED]> wrote:
> В Вск, 16/03/2008 в 00:01 -0600, C.W. Betts пишет:
>
> > Try setting the compiler flags to use -march=pentium-mmx . That is the max
> > setting for -march that qemu compiles on. also, make sure that the
> compiler
> > isn't sending any of th
В Вск, 16/03/2008 в 00:01 -0600, C.W. Betts пишет:
> Try setting the compiler flags to use -march=pentium-mmx . That is the max
> setting for -march that qemu compiles on. also, make sure that the compiler
> isn't sending any of the -msse functions.
>
> I tried to build qemu using -msse -march=
On Saturday 15 March 2008 09:13:02 am Peter Volkov wrote:
> В Сбт, 15/03/2008 в 14:20 +, Paul Brook пишет:
> > On Saturday 15 March 2008, Peter Volkov wrote:
> > > Hello.
> > >
> > > I just wanted to point developers attention to the following bug:
> > > bugs.gentoo.org/212351 , comment #11 and
On 3/15/08, Peter Volkov <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I just wanted to point developers attention to the following bug:
> bugs.gentoo.org/212351 , comment #11 and further. The problem is that
> qemu does not compile any more on x86. I've tried recent snapshot
> (2008-03-15_05) and th
Peter Volkov wrote:
> В Сбт, 15/03/2008 в 14:20 +, Paul Brook пишет:
>
>> On Saturday 15 March 2008, Peter Volkov wrote:
>>
>>> Hello.
>>>
>>> I just wanted to point developers attention to the following bug:
>>> bugs.gentoo.org/212351 , comment #11 and further. The problem is that
>>>
Paul Brook schrieb:
On Saturday 15 March 2008, Peter Volkov wrote:
Hello.
I just wanted to point developers attention to the following bug:
bugs.gentoo.org/212351 , comment #11 and further. The problem is that
qemu does not compile any more on x86. I've tried recent snapshot
(2008-03-15_05) and
В Сбт, 15/03/2008 в 14:20 +, Paul Brook пишет:
> On Saturday 15 March 2008, Peter Volkov wrote:
> > Hello.
> >
> > I just wanted to point developers attention to the following bug:
> > bugs.gentoo.org/212351 , comment #11 and further. The problem is that
> > qemu does not compile any more on x
On Saturday 15 March 2008, Peter Volkov wrote:
> Hello.
>
> I just wanted to point developers attention to the following bug:
> bugs.gentoo.org/212351 , comment #11 and further. The problem is that
> qemu does not compile any more on x86. I've tried recent snapshot
> (2008-03-15_05) and the problem
Hello.
I just wanted to point developers attention to the following bug:
bugs.gentoo.org/212351 , comment #11 and further. The problem is that
qemu does not compile any more on x86. I've tried recent snapshot
(2008-03-15_05) and the problem persist there.
The problem gentoo is that previous versi
Am 30.09.2007 um 17:54 schrieb Andreas Färber:
Am 30.09.2007 um 17:05 schrieb Andreas Färber:
Am 30.09.2007 um 16:37 schrieb J. Mayer:
If someone has a speedup idea for the __APPLE__ case, that could
still be applied separately.
I guess there are some already defined macros in the Apple
On Sun, 2007-09-30 at 17:05 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 16:37 schrieb J. Mayer:
>
> >> If someone has a speedup idea for the __APPLE__ case, that could
> >> still be applied separately.
> >
> > I guess there are some already defined macros in the Apple build
> > environmnet tha
Am 30.09.2007 um 17:05 schrieb Andreas Färber:
Am 30.09.2007 um 16:37 schrieb J. Mayer:
If someone has a speedup idea for the __APPLE__ case, that could
still be applied separately.
I guess there are some already defined macros in the Apple build
environmnet that should be used instead. But
Am 30.09.2007 um 16:37 schrieb J. Mayer:
If someone has a speedup idea for the __APPLE__ case, that could
still be applied separately.
I guess there are some already defined macros in the Apple build
environmnet that should be used instead. But I don't know too much
about
this environment.
On Sun, 2007-09-30 at 16:28 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 15:27 schrieb J. Mayer:
>
> > On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> >> Am 30.09.2007 um 14:17 schrieb J. Mayer:
> >>> Would this new definition solve the compilation failure ?
> >>>
> >>> #ifndef alway
Am 30.09.2007 um 15:27 schrieb J. Mayer:
On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
Am 30.09.2007 um 14:17 schrieb J. Mayer:
Would this new definition solve the compilation failure ?
#ifndef always_inline
#if (__GNUC__ < 3) || defined(__APPLE__)
#define always_inline inline
#el
On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 14:17 schrieb J. Mayer:
>
> > On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> >> Hi,
> >>
> >> Am 30.09.2007 um 13:45 schrieb J. Mayer:
> >>
> Anyone any idea what might've caused this build failure? I'm fa
Am 30.09.2007 um 14:17 schrieb J. Mayer:
On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
Hi,
Am 30.09.2007 um 13:45 schrieb J. Mayer:
Anyone any idea what might've caused this build failure? I'm fairly
certain I haven't messed with or updated the system headers.
have you just upd
On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> Hi,
>
> Am 30.09.2007 um 13:45 schrieb J. Mayer:
>
> >> Anyone any idea what might've caused this build failure? I'm fairly
> >> certain I haven't messed with or updated the system headers.
> >
> > have you just updated your CVS co ?
>
>
Hi,
Am 30.09.2007 um 13:45 schrieb J. Mayer:
Anyone any idea what might've caused this build failure? I'm fairly
certain I haven't messed with or updated the system headers.
have you just updated your CVS co ?
Yes.
Please try to comment the "always_inline" definition in vl.h /
exec-all.h.
On Sun, 2007-09-30 at 12:09 +0200, Andreas Färber wrote:
> Hello,
Hi,
> Anyone any idea what might've caused this build failure? I'm fairly
> certain I haven't messed with or updated the system headers.
have you just updated your CVS co ?
Please try to comment the "always_inline" definition in
Hello,
Anyone any idea what might've caused this build failure? I'm fairly
certain I haven't messed with or updated the system headers.
gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/Users/andreas/Q/
myqemu/target-sparc -I/Users/andreas/Q/myqemu -D__powerpc__ -
D_GNU_SOURCE -D_FILE_O
On 8/31/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
>
> Am 31.08.2007 um 21:45 schrieb Luca Tettamanti:
>
> > Andreas Färber ha scritto:
> >> Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:
> >>
> >>> One of the recent patches (dynticks) has broken compilation on Mac
> >>> OS X v10.4. Should thi
Am 31.08.2007 um 21:45 schrieb Luca Tettamanti:
Andreas Färber ha scritto:
Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:
One of the recent patches (dynticks) has broken compilation on Mac
OS X v10.4. Should this work on OS X or should this have been
limited to Linux?
Getting no answer o
Andreas Färber ha scritto:
> Am 25.08.2007 um 09:37 schrieb Andreas F=E4rber:
>
>> One of the recent patches (dynticks) has broken compilation on Mac
>> OS X v10.4. Should this work on OS X or should this have been
>> limited to Linux?
>
> Getting no answer on this I have prepared a quickfix which
Am 25.08.2007 um 09:37 schrieb Andreas Färber:
One of the recent patches (dynticks) has broken compilation on Mac
OS X v10.4. Should this work on OS X or should this have been
limited to Linux?
Getting no answer on this I have prepared a quickfix which wraps all
dynticks in conditional s
Hello,
One of the recent patches (dynticks) has broken compilation on Mac OS
X v10.4. Should this work on OS X or should this have been limited to
Linux?
...
Documentation yes
gcc-3.3 -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -I. -
D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_S
71 matches
Mail list logo