Cc'ing qemu-block.
On 4/5/19 11:02 AM, Helge Deller wrote:
[...]
> As another example, even if I only want to build "qemu-img", I still need
> to manually give the --enable-tcg-interpreter configure option.
You found a bug :)
On 05.04.19 10:26, Daniel P. Berrangé wrote:
> On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
>> Hi Peter,
>>
>> On 05.04.19 03:34, Peter Maydell wrote:
>>> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
If a non-release architecture is found, and it's known that there is no
On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Helge,
>
> On 4/5/19 9:56 AM, Helge Deller wrote:
> > On 05.04.19 03:34, Peter Maydell wrote:
> >> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> >>> If a non-release architecture is found, and it's known that there
Hi Helge,
On 4/5/19 9:56 AM, Helge Deller wrote:
> On 05.04.19 03:34, Peter Maydell wrote:
>> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
>>> If a non-release architecture is found, and it's known that there is no
>>> native TCG support for that CPU, automatically fall back to the TCI
>>>
On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
> Hi Peter,
>
> On 05.04.19 03:34, Peter Maydell wrote:
> > On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> >> If a non-release architecture is found, and it's known that there is no
> >> native TCG support for that CPU,
Hi Peter,
On 05.04.19 03:34, Peter Maydell wrote:
> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
>> If a non-release architecture is found, and it's known that there is no
>> native TCG support for that CPU, automatically fall back to the TCI
>> implementation instead of requesting the user
Hi Philippe,
On 04.04.19 21:24, Philippe Mathieu-Daudé wrote:
> Hi Helge,
>
> On 4/4/19 8:57 PM, Helge Deller wrote:
>> If a non-release architecture is found, and it's known that there is no
>> native TCG support for that CPU, automatically fall back to the TCI
>> implementation instead of
On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> If a non-release architecture is found, and it's known that there is no
> native TCG support for that CPU, automatically fall back to the TCI
> implementation instead of requesting the user to run configure again
> with the
Hi Helge,
On 4/4/19 8:57 PM, Helge Deller wrote:
> If a non-release architecture is found, and it's known that there is no
> native TCG support for that CPU, automatically fall back to the TCI
> implementation instead of requesting the user to run configure again
> with the
If a non-release architecture is found, and it's known that there is no
native TCG support for that CPU, automatically fall back to the TCI
implementation instead of requesting the user to run configure again
with the --enable-tcg-interpreter option.
This change simplifies building qemu in
On 4/4/19 11:17 AM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> The pam test generates a warning on Fedora 29 with -O3 compilation
> because the headers declare that the pam_conversation pointer to
> pam_start must be non-NULL. Change it to use the same 0
CC trivial
On Thu, Apr 04, 2019 at 10:17:25AM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> The pam test generates a warning on Fedora 29 with -O3 compilation
> because the headers declare that the pam_conversation pointer to
> pam_start must be non-NULL.
From: "Dr. David Alan Gilbert"
The pam test generates a warning on Fedora 29 with -O3 compilation
because the headers declare that the pam_conversation pointer to
pam_start must be non-NULL. Change it to use the same 0 initialised
structure as we actually use in qauthz.
Signed-off-by: Dr.
On Thu, Apr 04, 2019 at 08:59:14AM +0200, Thomas Huth wrote:
> On 04/04/2019 03.53, Peter Maydell wrote:
> > On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé wrote:
> >>
> >> On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote:
> >>> diff --git a/configure b/configure
> >>> index
On 04/04/2019 03.53, Peter Maydell wrote:
> On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé wrote:
>>
>> On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote:
>>> diff --git a/configure b/configure
>>> index 1c563a7027..8632267049 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@
On Wed, 3 Apr 2019 at 23:27, Daniel P. Berrangé wrote:
>
> On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote:
> > diff --git a/configure b/configure
> > index 1c563a7027..8632267049 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ;
On Thu, 4 Apr 2019 at 04:05, Eduardo Habkost wrote:
>
>
> CCing the right Eduardo. :)
Oops, sorry! Can I blame my email client's autocompletion? :-)
-- PMM
CCing the right Eduardo. :)
On Wed, Apr 03, 2019 at 10:16:15PM +0700, Peter Maydell wrote:
> On Wed, 3 Apr 2019 at 19:51, Helge Deller wrote:
>
> [cc'ing Eduardo as the seccomp submaintainer]
>
> > On a non-release architecture, the configure program aborts if the
> > --enable-seccomp flag
On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote:
> On a non-release architecture, the configure program aborts if the
> --enable-seccomp flag was given (with no way to work around it on the
> command line):
>
> ERROR: User requested feature libseccomp
> configure was not able
On 03.04.19 17:16, Peter Maydell wrote:
> On Wed, 3 Apr 2019 at 19:51, Helge Deller wrote:
>
> [cc'ing Eduardo as the seccomp submaintainer]
>
>> On a non-release architecture, the configure program aborts if the
>> --enable-seccomp flag was given (with no way to work around it on the
>> command
On Wed, 3 Apr 2019 at 22:16, Peter Maydell wrote:
>
> On Wed, 3 Apr 2019 at 19:51, Helge Deller wrote:
>
> [cc'ing Eduardo as the seccomp submaintainer]
>
> > On a non-release architecture, the configure program aborts if the
> > --enable-seccomp flag was given (with no way to work around it on
On Wed, 3 Apr 2019 at 19:51, Helge Deller wrote:
[cc'ing Eduardo as the seccomp submaintainer]
> On a non-release architecture, the configure program aborts if the
> --enable-seccomp flag was given (with no way to work around it on the
> command line):
>
> ERROR: User requested feature
On a non-release architecture, the configure program aborts if the
--enable-seccomp flag was given (with no way to work around it on the
command line):
ERROR: User requested feature libseccomp
configure was not able to find it.
libseccomp is not supported for host cpu parisc64
On 18/03/19 14:40, Peter Maydell wrote:
Normally configure identifies the source path by looking
at the location where the configure script itself exists.
We also provide a --source-path option which lets the user
manually override this.
There isn't really an obvious use case for the
On Mon, Mar 18, 2019 at 01:40:19PM +, Peter Maydell wrote:
> Normally configure identifies the source path by looking
> at the location where the configure script itself exists.
> We also provide a --source-path option which lets the user
> manually override this.
>
> There isn't really an
Normally configure identifies the source path by looking
at the location where the configure script itself exists.
We also provide a --source-path option which lets the user
manually override this.
There isn't really an obvious use case for the --source-path
option, and in commit
Hi, thanks for the comments.
On Fri, 15 Mar 2019 13:48:25 -0500
Eric Blake wrote:
> On 3/15/19 1:40 PM, Peter Maydell wrote:
>
> > If you do this after the point where we make the source path absolute, you
> > can skip the realpath (which avoids the problem that 'realpath' doesn't
> > exist
>
On 3/15/19 1:40 PM, Peter Maydell wrote:
> If you do this after the point where we make the source path absolute, you
> can skip the realpath (which avoids the problem that 'realpath' doesn't exist
> on OSX by default). It will also then be after the handling of the
> --source-path option
On 3/15/19 12:50 PM, Antonio Ospite wrote:
> From: Antonio Ospite
>
> The configure script breaks when the qemu source directory is in a path
> containing white spaces, in particular the list of targets is not
> correctly generated when calling "./configure --help".
>
> To avoid this issue,
On Fri, 15 Mar 2019 at 18:26, Antonio Ospite wrote:
>
> From: Antonio Ospite
>
> The configure script breaks when the qemu source directory is in a path
> containing white spaces, in particular the list of targets is not
> correctly generated when calling "./configure --help".
>
> To avoid this
From: Antonio Ospite
The configure script breaks when the qemu source directory is in a path
containing white spaces, in particular the list of targets is not
correctly generated when calling "./configure --help".
To avoid this issue, refuse to run the configure script if there are
spaces or
On Wed, Mar 13, 2019 at 05:31:57PM +, Daniel P. Berrangé wrote:
> The slirp code is not yet split off into a separate repository, so
> configuring QEMU to use slirp as a submodule is premature. This
> causes the non-existant "slirp" to be requested from git when syncing
> submodules. This in
Hi
On Wed, Mar 13, 2019 at 6:43 PM Daniel P. Berrangé wrote:
>
> The slirp code is not yet split off into a separate repository, so
> configuring QEMU to use slirp as a submodule is premature. This
> causes the non-existant "slirp" to be requested from git when syncing
> submodules. This in turn
The slirp code is not yet split off into a separate repository, so
configuring QEMU to use slirp as a submodule is premature. This
causes the non-existant "slirp" to be requested from git when syncing
submodules. This in turn appears to be cause of non-deterministic
failures some developers are
On 3/11/19 5:29 AM, Thomas Huth wrote:
> When running "make" in a build directory from the pre-Kconfig merge time,
> the build process currently fails with:
>
> make: *** No rule to make target `.../default-configs/pci.mak',
> needed by `aarch64-softmmu/config-devices.mak'. Stop.
>
> To make
When running "make" in a build directory from the pre-Kconfig merge time,
the build process currently fails with:
make: *** No rule to make target `.../default-configs/pci.mak',
needed by `aarch64-softmmu/config-devices.mak'. Stop.
To make sure that this problem at least goes away when the
On Fri, Mar 01, 2019 at 10:48:04AM -0600, Eric Blake wrote:
> On 3/1/19 10:33 AM, Daniel P. Berrangé wrote:
> > Unless overridden via an env var or configure arg, QEMU will only look
> > for the 'python' binary in $PATH. This is unhelpful on distros which
> > are only shipping Python 3.x (eg
On 3/1/19 10:33 AM, Daniel P. Berrangé wrote:
> Unless overridden via an env var or configure arg, QEMU will only look
> for the 'python' binary in $PATH. This is unhelpful on distros which
> are only shipping Python 3.x (eg Fedora) in their default install as,
> if they comply with PEP 394, the
Unless overridden via an env var or configure arg, QEMU will only look
for the 'python' binary in $PATH. This is unhelpful on distros which
are only shipping Python 3.x (eg Fedora) in their default install as,
if they comply with PEP 394, the bare 'python' binary won't exist.
This changes
On 2019-02-13 22:18, Thomas Petazzoni wrote:
> The current check to test if usbfs support should be compiled or not
> solely relies on the presence of , without
> actually checking that all definition used by Qemu are provided by
> this header file.
>
> With sufficiently old kernel headers, may
The current check to test if usbfs support should be compiled or not
solely relies on the presence of , without
actually checking that all definition used by Qemu are provided by
this header file.
With sufficiently old kernel headers, may be
present, but some of the definitions needed by Qemu
On 2/8/19 2:21 PM, Peter Maydell wrote:
> We have now managed to eradicate all the places in the codebase
> that triggered clang's -Waddress-of-packed-member warning. Remove
> the compiler flag that exempted it from our usual -Werror policy.
> This will prevent any new problematic code being added
On 2019-02-08 14:21, Peter Maydell wrote:
> We have now managed to eradicate all the places in the codebase
> that triggered clang's -Waddress-of-packed-member warning. Remove
> the compiler flag that exempted it from our usual -Werror policy.
> This will prevent any new problematic code being
We have now managed to eradicate all the places in the codebase
that triggered clang's -Waddress-of-packed-member warning. Remove
the compiler flag that exempted it from our usual -Werror policy.
This will prevent any new problematic code being added in future.
Signed-off-by: Peter Maydell
---
The NetBSD support in Intel HAXM has beem merged upstream and is functional.
Signed-off-by: Kamil Rytarowski
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index b18281c61f..89b889072d 100755
--- a/configure
+++ b/configure
@@ -819,6 +819,7 @@ DragonFly)
On 2/5/19 3:39 AM, Eric Blake wrote:
> POSIX says that it is better to use &&/|| and two separate test
> invocations than it is to try and use -a and -o (in fact, there
> are some tests that are inherently ambiguous to parse if the
> user passes in corner-case input like "(").
>
> Since we cannot
On Tue, 5 Feb 2019 at 02:46, Eric Blake wrote:
>
> POSIX says that it is better to use &&/|| and two separate test
> invocations than it is to try and use -a and -o (in fact, there
> are some tests that are inherently ambiguous to parse if the
> user passes in corner-case input like "(").
>
>
POSIX says that it is better to use &&/|| and two separate test
invocations than it is to try and use -a and -o (in fact, there
are some tests that are inherently ambiguous to parse if the
user passes in corner-case input like "(").
Since we cannot guarantee which shell runs configure, we cannot
On 1/24/19 12:29 PM, Peter Maydell wrote:
> On Thu, 24 Jan 2019 at 17:40, Eric Blake wrote:
>>
>> On 1/24/19 2:45 AM, Markus Armbruster wrote:
>>
Signed-off-by: Michael Tokarev
Revieved-by: Michael Tokarev
>>>
>>> Typo in Reviewed-by.
>>
>> Should we tighten checkpatch.pl to flag
On Thu, 24 Jan 2019 at 17:40, Eric Blake wrote:
>
> On 1/24/19 2:45 AM, Markus Armbruster wrote:
>
> >> Signed-off-by: Michael Tokarev
> >> Revieved-by: Michael Tokarev
> >
> > Typo in Reviewed-by.
>
> Should we tighten checkpatch.pl to flag suspicious-looking 'xxx-by:'
> tags, to catch
On 1/24/19 2:45 AM, Markus Armbruster wrote:
>> Signed-off-by: Michael Tokarev
>> Revieved-by: Michael Tokarev
>
> Typo in Reviewed-by.
Should we tighten checkpatch.pl to flag suspicious-looking 'xxx-by:'
tags, to catch instances of typos?
--
Eric Blake, Principal Software Engineer
Red Hat,
Michael Tokarev writes:
> 21.01.2019 18:17, Peter Maydell wrote:
>> On Mon, 21 Jan 2019 at 14:49, Anthony PERARD
>> wrote:
>>>
>>> When Xen is detected via pkg-config, it isn't necessary to modify
>>> LDFLAGS as modifying libs_softmmu is enough.
>>>
>>> Reported-by: Peter Maydell
>>>
On 1/23/19 10:33 AM, Daniel P. Berrangé wrote:
> On Tue, Jan 22, 2019 at 07:20:35PM +, Peter Maydell wrote:
>> On Tue, 22 Jan 2019 at 19:05, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> Currently if we try to build QEMU on OpenBSD with SDL disabled, we get:
>>>
>>> $ ./configure
On Tue, Jan 22, 2019 at 07:20:35PM +, Peter Maydell wrote:
> On Tue, 22 Jan 2019 at 19:05, Philippe Mathieu-Daudé
> wrote:
> >
> > Currently if we try to build QEMU on OpenBSD with SDL disabled, we get:
> >
> > $ ./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 --python=python2.7
> >
On Tue, 22 Jan 2019 at 19:05, Philippe Mathieu-Daudé wrote:
>
> Currently if we try to build QEMU on OpenBSD with SDL disabled, we get:
>
> $ ./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 --python=python2.7
> --disable-sdl
>
> ERROR: sdl not found or disabled, can not use sdl audio
Currently if we try to build QEMU on OpenBSD with SDL disabled, we get:
$ ./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 --python=python2.7
--disable-sdl
ERROR: sdl not found or disabled, can not use sdl audio driver
Since SDL is not a requirement for OpenBSD, let it be optional (we
21.01.2019 18:17, Peter Maydell wrote:
On Mon, 21 Jan 2019 at 14:49, Anthony PERARD wrote:
When Xen is detected via pkg-config, it isn't necessary to modify
LDFLAGS as modifying libs_softmmu is enough.
Reported-by: Peter Maydell
Signed-off-by: Anthony PERARD
---
configure | 1 -
1 file
Its last uses was removed by: 6d7c06c213ddcfabcafdc178ccef81736f85a7c2
"Remove broken Xen PV domain builder".
Signed-off-by: Anthony PERARD
---
configure | 19 ---
1 file changed, 19 deletions(-)
diff --git a/configure b/configure
index 98b270974d..8684a6e5ef 100755
---
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 January 2019 17:07
> To: qemu-devel@nongnu.org
> Cc: Stefano Stabellini ; Paul Durrant
> ; xen-de...@lists.xenproject.org; Anthony Perard
>
> Subject: [PATCH] configure: xen: Stop build-testing for
On Mon, 21 Jan 2019 at 14:49, Anthony PERARD wrote:
>
> When Xen is detected via pkg-config, it isn't necessary to modify
> LDFLAGS as modifying libs_softmmu is enough.
>
> Reported-by: Peter Maydell
> Signed-off-by: Anthony PERARD
> ---
> configure | 1 -
> 1 file changed, 1 deletion(-)
>
>
On 1/21/19 3:48 PM, Anthony PERARD wrote:
> When Xen is detected via pkg-config, it isn't necessary to modify
> LDFLAGS as modifying libs_softmmu is enough.
>
> Reported-by: Peter Maydell
> Signed-off-by: Anthony PERARD
> ---
> configure | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
When Xen is detected via pkg-config, it isn't necessary to modify
LDFLAGS as modifying libs_softmmu is enough.
Reported-by: Peter Maydell
Signed-off-by: Anthony PERARD
---
configure | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure b/configure
index 12fd34f30b..98b270974d 100755
---
On 1/17/19 12:07 PM, Peter Maydell wrote:
> On Thu, 17 Jan 2019 at 17:14, Thomas Huth wrote:
>>
>> On Linux (and maybe some BSDs), we require libutil for the openpty()
>> function. However, this library is not available on some other systems, so
>> we currently use a fragile if-statement in the
On Thu, 17 Jan 2019 at 17:14, Thomas Huth wrote:
>
> On Linux (and maybe some BSDs), we require libutil for the openpty()
> function. However, this library is not available on some other systems, so
> we currently use a fragile if-statement in the configure script to check
> whether we need the
On 17/01/19 18:14, Thomas Huth wrote:
> On Linux (and maybe some BSDs), we require libutil for the openpty()
> function. However, this library is not available on some other systems, so
> we currently use a fragile if-statement in the configure script to check
> whether we need the library or not.
On 1/17/19 11:14 AM, Thomas Huth wrote:
> On Linux (and maybe some BSDs), we require libutil for the openpty()
> function. However, this library is not available on some other systems, so
> we currently use a fragile if-statement in the configure script to check
> whether we need the library or
On 1/17/19 6:14 PM, Thomas Huth wrote:
> On Linux (and maybe some BSDs), we require libutil for the openpty()
> function. However, this library is not available on some other systems, so
> we currently use a fragile if-statement in the configure script to check
> whether we need the library or
On Linux (and maybe some BSDs), we require libutil for the openpty()
function. However, this library is not available on some other systems, so
we currently use a fragile if-statement in the configure script to check
whether we need the library or not. Unfortunately, we also hard-coded a
"-lutil"
On 2019-01-14 16:23, Thomas Huth wrote:
> On 2019-01-14 16:02, Eric Blake wrote:
>> On 1/14/19 8:53 AM, Thomas Huth wrote:
[...]
>>> The patch is only changing libiscsi_cflags, so it's not affecting the
>>> entire project, but just the files that use libiscsi.
>>
>> Even so, limiting the damage to
On 2019-01-14 16:02, Eric Blake wrote:
> On 1/14/19 8:53 AM, Thomas Huth wrote:
>> On 2019-01-14 15:50, Eric Blake wrote:
>>> On 1/14/19 8:31 AM, Daniel P. Berrangé wrote:
>>>
>
> Can we suppress the warnings with #pragma instead ?
> That would avoid compiling the .o file with
On 1/14/19 3:36 PM, Thomas Huth wrote:
> On 2019-01-14 15:31, Philippe Mathieu-Daudé wrote:
>> On 1/14/19 2:46 PM, Thomas Huth wrote:
>>> The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
>>> "inline" prototype definitions which GCC refuses to compile in its
>>> gnu99 mode:
>>>
>>>
On Mon, Jan 14, 2019 at 03:53:48PM +0100, Thomas Huth wrote:
> On 2019-01-14 15:50, Eric Blake wrote:
> > On 1/14/19 8:31 AM, Daniel P. Berrangé wrote:
> >
> >>>
> >>> Can we suppress the warnings with #pragma instead ?
> >>> That would avoid compiling the .o file with different
> >>> C
On 1/14/19 8:53 AM, Thomas Huth wrote:
> On 2019-01-14 15:50, Eric Blake wrote:
>> On 1/14/19 8:31 AM, Daniel P. Berrangé wrote:
>>
Can we suppress the warnings with #pragma instead ?
That would avoid compiling the .o file with different
C semantics.
>>>
>>> IIUC this is a
On 1/14/19 8:31 AM, Daniel P. Berrangé wrote:
>>
>> Can we suppress the warnings with #pragma instead ?
>> That would avoid compiling the .o file with different
>> C semantics.
>
> IIUC this is a built-in warning you can't disable, except by changing
> the compilation mode to have gnu89 inline
On 1/14/19 2:46 PM, Thomas Huth wrote:
> The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
> "inline" prototype definitions which GCC refuses to compile in its
> gnu99 mode:
>
> In file included from block/iscsi.c:52:0:
> /usr/include/iscsi/scsi-lowlevel.h:810:13: error: inline
On 2019-01-14 15:50, Eric Blake wrote:
> On 1/14/19 8:31 AM, Daniel P. Berrangé wrote:
>
>>>
>>> Can we suppress the warnings with #pragma instead ?
>>> That would avoid compiling the .o file with different
>>> C semantics.
>>
>> IIUC this is a built-in warning you can't disable, except by
On 2019-01-14 15:31, Daniel P. Berrangé wrote:
> On Mon, Jan 14, 2019 at 01:52:01PM +, Peter Maydell wrote:
>> On Mon, 14 Jan 2019 at 13:47, Thomas Huth wrote:
>>>
>>> The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
>>> "inline" prototype definitions which GCC refuses to
On 2019-01-14 15:31, Philippe Mathieu-Daudé wrote:
> On 1/14/19 2:46 PM, Thomas Huth wrote:
>> The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
>> "inline" prototype definitions which GCC refuses to compile in its
>> gnu99 mode:
>>
>> In file included from block/iscsi.c:52:0:
>>
On Mon, Jan 14, 2019 at 01:52:01PM +, Peter Maydell wrote:
> On Mon, 14 Jan 2019 at 13:47, Thomas Huth wrote:
> >
> > The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
> > "inline" prototype definitions which GCC refuses to compile in its
> > gnu99 mode:
> >
> > In file
The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
"inline" prototype definitions which GCC refuses to compile in its
gnu99 mode:
In file included from block/iscsi.c:52:0:
/usr/include/iscsi/scsi-lowlevel.h:810:13: error: inline function
‘scsi_set_uint16’ declared but never defined
On Mon, 14 Jan 2019 at 13:47, Thomas Huth wrote:
>
> The header "scsi-lowlevel.h" of libiscsi 1.9.0 contains some bad
> "inline" prototype definitions which GCC refuses to compile in its
> gnu99 mode:
>
> In file included from block/iscsi.c:52:0:
> /usr/include/iscsi/scsi-lowlevel.h:810:13:
On 2019-01-14 13:37, Peter Maydell wrote:
> On Mon, 14 Jan 2019 at 12:24, Thomas Huth wrote:
>>
>> We want to build our s390-ccw bios with -march=z900 so that it also
>> works with the oldest s390x CPU that we support with TCG. However,
>> Clang on s390x does not support -march=z900 anymore, so
On Mon, 14 Jan 2019 at 12:24, Thomas Huth wrote:
>
> We want to build our s390-ccw bios with -march=z900 so that it also
> works with the oldest s390x CPU that we support with TCG. However,
> Clang on s390x does not support -march=z900 anymore, so we can not
> use this compiler to build the
We want to build our s390-ccw bios with -march=z900 so that it also
works with the oldest s390x CPU that we support with TCG. However,
Clang on s390x does not support -march=z900 anymore, so we can not
use this compiler to build the s390-ccw bios. Thus add a proper test
to the configure script to
On 2019-01-09 15:20, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> On 2019-01-09 14:10, Markus Armbruster wrote:
>>> Thomas Huth writes:
>>>
On 2019-01-09 12:44, Daniel P. Berrangé wrote:
> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
>> On 2019-01-09 11:58,
Thomas Huth writes:
> On 2019-01-09 14:10, Markus Armbruster wrote:
>> Thomas Huth writes:
>>
>>> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
> On 2019-01-09 11:58, Daniel P. Berrangé wrote:
>> On Mon, Jan 07, 2019 at
On 2019-01-09 14:27, Daniel P. Berrangé wrote:
> On Wed, Jan 09, 2019 at 02:20:02PM +0100, Thomas Huth wrote:
>> On 2019-01-09 13:58, Daniel P. Berrangé wrote:
>>> On Wed, Jan 09, 2019 at 01:52:02PM +0100, Thomas Huth wrote:
On 2019-01-09 12:44, Daniel P. Berrangé wrote:
> On Wed, Jan 09,
On 2019-01-09 13:58, Daniel P. Berrangé wrote:
> On Wed, Jan 09, 2019 at 01:52:02PM +0100, Thomas Huth wrote:
>> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
>>> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
On 2019-01-09 11:58, Daniel P. Berrangé wrote:
> On Mon, Jan 07,
On 2019-01-09 14:10, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
>>> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
On 2019-01-09 11:58, Daniel P. Berrangé wrote:
> On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth
On Wed, Jan 09, 2019 at 02:20:02PM +0100, Thomas Huth wrote:
> On 2019-01-09 13:58, Daniel P. Berrangé wrote:
> > On Wed, Jan 09, 2019 at 01:52:02PM +0100, Thomas Huth wrote:
> >> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
> >>> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
>
On Wed, Jan 09, 2019 at 01:52:02PM +0100, Thomas Huth wrote:
> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
> > On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
> >> On 2019-01-09 11:58, Daniel P. Berrangé wrote:
> >>> On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
>
Thomas Huth writes:
> On 2019-01-09 12:44, Daniel P. Berrangé wrote:
>> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
>>> On 2019-01-09 11:58, Daniel P. Berrangé wrote:
On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
> Different versions of GCC and Clang use
On 2019-01-09 12:44, Daniel P. Berrangé wrote:
> On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
>> On 2019-01-09 11:58, Daniel P. Berrangé wrote:
>>> On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
Different versions of GCC and Clang use different versions of the C
On Wed, Jan 09, 2019 at 12:25:43PM +0100, Thomas Huth wrote:
> On 2019-01-09 11:58, Daniel P. Berrangé wrote:
> > On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
> >> Different versions of GCC and Clang use different versions of the C
> >> standard.
> >> This repeatedly caused
On 2019-01-09 11:58, Daniel P. Berrangé wrote:
> On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
>> Different versions of GCC and Clang use different versions of the C standard.
>> This repeatedly caused problems already, e.g. with duplicated typedefs:
>>
>>
On Mon, Jan 07, 2019 at 11:45:26AM +0100, Thomas Huth wrote:
> Different versions of GCC and Clang use different versions of the C standard.
> This repeatedly caused problems already, e.g. with duplicated typedefs:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05829.html
>
> or
Different versions of GCC and Clang use different versions of the C standard.
This repeatedly caused problems already, e.g. with duplicated typedefs:
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05829.html
or with for-loop variable initializers:
On Tue, Nov 27, 2018 at 07:50:54PM +0100, Paolo Bonzini wrote:
> On 23/11/18 10:01, Roman Kagan wrote:
> > elf2dmp is keyed on "$posix" = "yes", but "$posix" doesn't seem to be
> > set anywhere.
> >
> > The original intent was presumably to skip building it on Windows, so
> > check for "$mingw32"
On 23/11/18 10:01, Roman Kagan wrote:
> elf2dmp is keyed on "$posix" = "yes", but "$posix" doesn't seem to be
> set anywhere.
>
> The original intent was presumably to skip building it on Windows, so
> check for "$mingw32" = "no" instead.
>
> Signed-off-by: Roman Kagan
> ---
> configure | 2 +-
On 23/11/18 10:01, Roman Kagan wrote:
> elf2dmp is keyed on "$posix" = "yes", but "$posix" doesn't seem to be
> set anywhere.
>
> The original intent was presumably to skip building it on Windows, so
> check for "$mingw32" = "no" instead.
>
> Signed-off-by: Roman Kagan
> ---
> configure | 2 +-
101 - 200 of 1161 matches
Mail list logo
