Am 09.07.2014 um 12:28 hat Liu Yuan geschrieben:
Cc: Kevin Wolf kw...@redhat.com
Signed-off-by: Liu Yuan namei.u...@gmail.com
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 7dd43fd..684fcdf 100755
--- a/configure
+++
Cc: Kevin Wolf kw...@redhat.com
Signed-off-by: Liu Yuan namei.u...@gmail.com
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 7dd43fd..684fcdf 100755
--- a/configure
+++ b/configure
@@ -3996,7 +3996,7 @@ if test $libnfs != no ; then
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
configure | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 7102964..adff12e 100755
--- a/configure
+++ b/configure
@@ -3066,7 +3066,8 @@ if test $glusterfs != no ; then
fi
else
19.06.2014 17:15, Sergey Fedorov wrote:
The only use for GPROF_CFLAGS is in main makefile, but this variable put
only to taget config file which is not included to the main makefile.
Lets put gprof config variables to host config file.
I'm not sure I follow.
First of all, GPROF_CFLAGS is
On 24.06.2014 20:06, Michael Tokarev wrote:
19.06.2014 17:15, Sergey Fedorov wrote:
The only use for GPROF_CFLAGS is in main makefile, but this variable put
only to taget config file which is not included to the main makefile.
Lets put gprof config variables to host config file.
I'm not sure
The only use for GPROF_CFLAGS is in main makefile, but this variable put
only to taget config file which is not included to the main makefile.
Lets put gprof config variables to host config file.
Signed-off-by: Sergey Fedorov serge.f...@gmail.com
---
configure | 6 +-
1 file changed, 5
Reorder the code so that the existing config.log file is not modified
by configure when --help is used.
Signed-off-by: Giuseppe Scrivano gscri...@redhat.com
---
configure | 782 +++---
1 file changed, 391 insertions(+), 391 deletions(-)
On Tue, Apr 29, 2014 at 08:21:16AM +0200, Stefan Weil wrote:
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weil s...@weilnetz.de
The Tuesday 29 Apr 2014 à 08:21:16 (+0200), Stefan Weil wrote :
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weil
Hi,
+if test $gtkabi = ; then
+# The GTK ABI was not specified explicitly, so try whether 2.0 is
available.
+# Use 3.0 as a fallback if that is available.
+if $pkg_config --exists gtk+-2.0 = 2.18.0; then
+gtkabi=2.0
+elif $pkg_config --exists gtk+-3.0 = 3.0.0;
Am 19.05.2014 08:19, schrieb Gerd Hoffmann:
Hi,
+if test $gtkabi = ; then
+# The GTK ABI was not specified explicitly, so try whether 2.0 is
available.
+# Use 3.0 as a fallback if that is available.
+if $pkg_config --exists gtk+-2.0 = 2.18.0; then
+gtkabi=2.0
+
Hi,
Shouldn't we probe for gtk3 first?
That sounds reasonable, but would result in a non trivial change for all
developers who build on a system with both GTK versions. I tried to
preserve the current default (2.0) as far as possible.
The differences between gtk2 + gtk3 are not that big,
When libtool support was added to configure, the new temporary files
were left out of the list of files cleaned up on exit; this results
in a lot of stale .lo files being left around in /tmp. Worse, libtool
creates a /tmp/.libs directory which we can't easily clean up.
Put all our temporary files
On 05/19/2014 11:19 AM, Peter Maydell wrote:
When libtool support was added to configure, the new temporary files
were left out of the list of files cleaned up on exit; this results
in a lot of stale .lo files being left around in /tmp. Worse, libtool
creates a /tmp/.libs directory which we
On 19 May 2014 18:46, Eric Blake ebl...@redhat.com wrote:
On 05/19/2014 11:19 AM, Peter Maydell wrote:
-# NB: do not call exit in the trap handler; this is buggy with some
shells;
-# see 1285349658-3122-1-git-send-email-loic.min...@linaro.org
-trap rm -f $TMPC $TMPO $TMPCXX $TMPE EXIT INT
The configure option --with-gtkabi=3.0 is still supported, but no longer
needed when GTK+-2.0 is missing. When no GTK+ ABI is selected by the
user, configure first tries 2.0, then 3.0.
For some platforms (e.g. Windows) newer binaries of GTK+ are only
available for GTK+ 3.0. Now building on these
On 14 May 2014 23:47, Max Reitz mre...@redhat.com wrote:
On 14.05.2014 16:26, Peter Maydell wrote:
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from clean.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
If
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from clean.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
If somebody would like to review this I'll apply it to master as
a buildfix...
configure | 1 +
1 file
Am 14.05.2014 um 16:26 hat Peter Maydell geschrieben:
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from clean.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
If somebody would like to review this I'll apply
On 14 May 2014 15:32, Kevin Wolf kw...@redhat.com wrote:
Am 14.05.2014 um 16:26 hat Peter Maydell geschrieben:
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from clean.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Am 14.05.2014 um 16:46 hat Peter Maydell geschrieben:
On 14 May 2014 15:32, Kevin Wolf kw...@redhat.com wrote:
Am 14.05.2014 um 16:26 hat Peter Maydell geschrieben:
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from
On 14.05.2014 16:26, Peter Maydell wrote:
Before we write common.env to the tests/qemu-iotests directory, ensure
that it exists. This fixes out-of-tree builds from clean.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
If somebody would like to review this I'll apply it to master as
a
When libtool support was added to configure, the new temporary files
were left out of the list of files cleaned up on exit; this results
in a lot of stale .lo files being left around in /tmp. Worse, libtool
creates a /tmp/.libs directory which we can't easily clean up.
Put all our temporary files
On 05/06/2014 07:17 AM, Peter Maydell wrote:
When libtool support was added to configure, the new temporary files
were left out of the list of files cleaned up on exit; this results
in a lot of stale .lo files being left around in /tmp. Worse, libtool
creates a /tmp/.libs directory which we
On 6 May 2014 15:36, Eric Blake ebl...@redhat.com wrote:
mktemp is not POSIX. BSD mktemp lacks -t:
http://www.freebsd.org/cgi/man.cgi?query=mktempapropos=0sektion=1manpath=Red+Hat+Linux%2Fi386+9format=html
Sigh.
and there are probably systems that lack mktemp(1) altogether. You'll
need to
On 05/06/2014 08:53 AM, Peter Maydell wrote:
# Create a (secure) tmp directory for tmp files.
{
tmp=`(umask 077 mktemp -d ./confXX) 2/dev/null`
test -d $tmp
} ||
{
tmp=./conf$$-$RANDOM
(umask 077 mkdir $tmp)
} || as_fn_error $? cannot create a temporary directory in .
Il 02/05/2014 13:41, Michael Tokarev ha scritto:
Commit e26110cfc67d48 added a check for shacmd to create a hash
for modules. This check in configure is using bash construct
to redirect both stdout and stderr, whcih does fun things on some
shells. Get rid of it, use standard redirection
On Fri, 05/02 15:41, Michael Tokarev wrote:
Commit e26110cfc67d48 added a check for shacmd to create a hash
for modules. This check in configure is using bash construct
to redirect both stdout and stderr, whcih does fun things on some
s/whcih/which
shells. Get rid of it, use standard
On Tue, Apr 29, 2014 at 08:21:16AM +0200, Stefan Weil wrote:
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weil s...@weilnetz.de
Commit e26110cfc67d48 added a check for shacmd to create a hash
for modules. This check in configure is using bash construct
to redirect both stdout and stderr, whcih does fun things on some
shells. Get rid of it, use standard redirection instead.
Cc: Fam Zheng f...@redhat.com
Signed-off-by:
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
I'm not sure whether this patch is trivial enough for
On 04/29/2014 02:21 PM, Stefan Weil wrote:
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weils...@weilnetz.de
Reviewed-by: Qiao
The Tuesday 29 Apr 2014 à 08:21:16 (+0200), Stefan Weil wrote :
Those options were not enabled by default, even when the build
environment would have supported them, so the corresponding
code was not compiled in normal test builds like on build bots.
Signed-off-by: Stefan Weil
Il 28/04/2014 14:21, Michael S. Tsirkin ha scritto:
A more practical way is when make runs configure automatically:
1. cd firstpath/; ./configure
SRC_PATH=firstpath/ is written into config_host.mak
2. cd secondpath/; touch configure; make
make now runs firstpath/configure, so configure
When source directory can be arrived at by two paths,
configure might misdetect an out of tree build.
The simplest way to trigger the problem is running
configure using a full path. E.g. (firstpath refers to qemu source
tree):
ln -s firstpath secondpath
cd firstpath
On 04/28/2014 06:21 AM, Michael S. Tsirkin wrote:
When source directory can be arrived at by two paths,
configure might misdetect an out of tree build.
The simplest way to trigger the problem is running
configure using a full path. E.g. (firstpath refers to qemu source
tree):
ln -s
Eric Blake ebl...@redhat.com writes:
On 04/28/2014 06:21 AM, Michael S. Tsirkin wrote:
When source directory can be arrived at by two paths,
configure might misdetect an out of tree build.
The simplest way to trigger the problem is running
configure using a full path. E.g. (firstpath refers
On 04/21/2014 10:16 PM, Fam Zheng wrote:
On Mon, 04/21 19:09, Cole Robinson wrote:
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and change
On 04/21/2014 10:38 PM, Paolo Bonzini wrote:
Il 21/04/2014 19:09, Cole Robinson ha scritto:
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and
john.liuli john.li...@huawei.com writes:
libfdt_env.h is missing in some stable installs (1.3.0-3),
some released linux distributions(e.g. Ubuntu 12.04) depending
on it still complain missing libfdt even if already installed.
So give more detailed hint for such OS users.
Signed-off-by: Liu
On 21 April 2014 07:18, john.liuli john.li...@huawei.com wrote:
libfdt_env.h is missing in some stable installs (1.3.0-3),
some released linux distributions(e.g. Ubuntu 12.04) depending
on it still complain missing libfdt even if already installed.
So give more detailed hint for such OS users.
On 2014/4/22 17:38, john.liuli wrote:
john.liuli john.li...@huawei.com writes:
libfdt_env.h is missing in some stable installs (1.3.0-3), some
released linux distributions(e.g. Ubuntu 12.04) depending on it still
complain missing libfdt even if already installed.
So give more detailed hint
john.liuli john.li...@huawei.com writes:
On 2014/4/22 17:38, john.liuli wrote:
john.liuli john.li...@huawei.com writes:
libfdt_env.h is missing in some stable installs (1.3.0-3), some
released linux distributions(e.g. Ubuntu 12.04) depending on it still
complain missing libfdt even if
On 2014/4/22 19:56, john.liuli wrote:
On 21 April 2014 07:18, john.liuli john.li...@huawei.com wrote:
libfdt_env.h is missing in some stable installs (1.3.0-3), some
released linux distributions(e.g. Ubuntu 12.04) depending on it still
complain missing libfdt even if already installed.
So
libfdt_env.h is missing in some stable installs (1.3.0-3),
some released linux distributions(e.g. Ubuntu 12.04) depending
on it still complain missing libfdt even if already installed.
So give more detailed hint for such OS users.
Signed-off-by: Liu Li john.li...@huawei.com
---
configure |4
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and change --enable-tpm to --disable-tpm if
people still want an option to compile it out.
On Mon, 04/21 19:09, Cole Robinson wrote:
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and change --enable-tpm to --disable-tpm if
people
Il 21/04/2014 19:09, Cole Robinson ha scritto:
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and change --enable-tpm to --disable-tpm if
people
There are two paths to show help and exit, one is with -h or --help,
one is with invalid options.
Only exit 1 with the latter case.
Signed-off-by: Fam Zheng f...@redhat.com
---
configure | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index
18.04.2014 10:25, Fam Zheng wrote:
There are two paths to show help and exit, one is with -h or --help,
one is with invalid options.
Only exit 1 with the latter case.
I'd rather put `exit 1' right in invalid option case, instead of jumping
to help. Because help output is huge, and it is
On 17 April 2014 22:24, Doug Kwan dougk...@google.com wrote:
This patch adds a new target for running ppc64 little-endian binaries in
user mode. Only change to configure is included in this patch. Patch for
loading and executing LE binaries will be submitted later.
Please put the configure
The help text for the --enable-debug-info and --disable-debug-info
command line options was misindented: delete the stray extra space
and bring it in to line with everything else.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2
On Fri, Mar 14, 2014 at 09:09:10PM +0100, Stefan Weil wrote:
It is only used with the simple trace backend.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
configure |2 ++
1 file changed, 2 insertions(+)
Thanks, applied to my tracing-next tree:
It is only used with the simple trace backend.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
configure |2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 1efb438..6eebd2c 100755
--- a/configure
+++ b/configure
@@ -4092,7 +4092,9 @@ echo libcap-ng support
The compiler flag -Werror is printed (or not printed) as any other
compiler flag which is part of QEMU_CFLAGS.
Therefore an extra output line for -Werror is redundant and can be removed.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
configure |1 -
1 file changed, 1 deletion(-)
diff
On Do, 2014-03-06 at 18:13 +0100, Stefan Weil wrote:
Instead of
spice support no (/)
configure now prints
spice support no
Signed-off-by: Stefan Weil s...@weilnetz.de
Added to spice patch queue.
thanks,
Gerd
./configure --help
make
will try to re-run configure with --help
which isn't what was intended.
The reason is that config.status was written
even on configure error.
Defer writing config.status until configure
has completed successfully.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
On 9 March 2014 15:41, Michael S. Tsirkin m...@redhat.com wrote:
./configure --help
make
will try to re-run configure with --help
which isn't what was intended.
The reason is that config.status was written
even on configure error.
Defer writing config.status until configure
has completed
Those versions don't fully support __int128_t.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Weil s...@weilnetz.de
---
See http://stackoverflow.com/questions/16447808/bug-with-int128-t-in-clang
for more details. Debian wheezy uses clang 3.0 and shows this bug.
I did not test whether the QEMU
Instead of
spice support no (/)
configure now prints
spice support no
Signed-off-by: Stefan Weil s...@weilnetz.de
---
configure |4
1 file changed, 4 insertions(+)
diff --git a/configure b/configure
index 6ccadc3..212dcd7 100755
--- a/configure
+++ b/configure
@@
On 28 February 2014 17:19, Richard Henderson r...@twiddle.net wrote:
On 02/26/2014 01:53 PM, Peter Maydell wrote:
In QEMU we don't make any use at all of the common symbol
functionality, so we can avoid this problem entirely simply
by compiling with -fno-common. Enable this option for all
On 02/26/2014 01:53 PM, Peter Maydell wrote:
In QEMU we don't make any use at all of the common symbol
functionality, so we can avoid this problem entirely simply
by compiling with -fno-common. Enable this option for all
builds, not just MacOSX, so that if we ever inadvertently
introduce
MacOSX doesn't pull .o files from .a archives if the symbol that it
requires is one which the .o file defines as a common symbol.
(Common symbols are those declared without extern; the linker
will merge together common symbols with the same name, so
redeclaring the same variable in two compilation
Am 24.02.2014 20:08, schrieb Peter Maydell:
gcc's C++ compiler complains about being passed some -W options
which make sense for C but not for C++. This means we mustn't try
a C++ compile with QEMU_CFLAGS, but only with a filtered version
that removes the offending options. This filtering was
On 24 February 2014 19:08, Peter Maydell peter.mayd...@linaro.org wrote:
gcc's C++ compiler complains about being passed some -W options
which make sense for C but not for C++. This means we mustn't try
a C++ compile with QEMU_CFLAGS, but only with a filtered version
that removes the offending
On 20 February 2014 15:10, Peter Maydell peter.mayd...@linaro.org wrote:
Check that the C++ compiler works with the C compiler; if it
does not, then don't pass CXX to the build process. This
fixes a regression where QEMU was no longer building if the
build environment didn't have a C++
gcc's C++ compiler complains about being passed some -W options
which make sense for C but not for C++. This means we mustn't try
a C++ compile with QEMU_CFLAGS, but only with a filtered version
that removes the offending options. This filtering was already being
done for uses of C++ in the build
On Mon, 24 Feb 2014 19:08:18 +
Peter Maydell peter.mayd...@linaro.org wrote:
gcc's C++ compiler complains about being passed some -W options
which make sense for C but not for C++. This means we mustn't try
a C++ compile with QEMU_CFLAGS, but only with a filtered version
that removes the
Check that the C++ compiler works with the C compiler; if it
does not, then don't pass CXX to the build process. This
fixes a regression where QEMU was no longer building if the
build environment didn't have a C++ compiler (introduced
in commit 3144f78b, which incorrectly assumed that rules.mak
On Thu, 20 Feb 2014 15:10:16 +
Peter Maydell peter.mayd...@linaro.org wrote:
Check that the C++ compiler works with the C compiler; if it
does not, then don't pass CXX to the build process. This
fixes a regression where QEMU was no longer building if the
build environment didn't have a
On 02/21/2014 02:58 AM, Thomas Huth wrote:
On Thu, 20 Feb 2014 15:10:16 +
Peter Maydell peter.mayd...@linaro.org wrote:
Check that the C++ compiler works with the C compiler; if it
does not, then don't pass CXX to the build process. This
fixes a regression where QEMU was no longer
On Tue, Feb 04, 2014 at 09:56:38AM +1100, Chris Johns wrote:
On 3/02/2014 9:29 pm, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 03:26:15PM +1100, Chris Johns wrote:
Building against with a recent glib in a custom prefix fails because
the gthread cflags in the pkg-config file do not have
On 4/02/2014 8:59 pm, Daniel P. Berrange wrote:
On Linux there are more flags present in gthread-2.0.pc that are not
present in glib-2.0.pc:
Name: GThread
Description: Thread support for GLib
Requires: glib-2.0
Version: 2.38.2
Libs: -L${libdir} -lgthread-2.0 -pthread
Cflags:
On Mon, Feb 03, 2014 at 03:26:15PM +1100, Chris Johns wrote:
Building against with a recent glib in a custom prefix fails because
the gthread cflags in the pkg-config file do not have the correct path
while the glib pc file does.
Signed-off-by: Chris Johns chr...@rtems.org
---
configure |
On 3/02/2014 9:29 pm, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 03:26:15PM +1100, Chris Johns wrote:
Building against with a recent glib in a custom prefix fails because
the gthread cflags in the pkg-config file do not have the correct path
while the glib pc file does.
Signed-off-by:
On 3 February 2014 22:56, Chris Johns chr...@rtems.org wrote:
On 3/02/2014 9:29 pm, Daniel P. Berrange wrote:
This change will cause -pthread linker + compiler flag to be lost.
I see in gthread-2.0.pc ..
Libs: -L${libdir} -lgthread-2.0
Cflags: -D_REENTRANT
and qemu includes 'glib.h'.
Building against with a recent glib in a custom prefix fails because
the gthread cflags in the pkg-config file do not have the correct path
while the glib pc file does.
Signed-off-by: Chris Johns chr...@rtems.org
---
configure | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
On 23 January 2014 06:21, Stefan Weil s...@weilnetz.de wrote:
My personal impression is that the current hints in configure are
sufficient (with the one exception DTC) and that the QEMU wiki is a
better place to document build dependencies for the different platforms.
I tend to agree, with the
Stefan Weil s...@weilnetz.de writes:
Am 23.01.2014 05:54, schrieb Stewart Smith:
diff --git a/configure b/configure
index 3782a6a..87303f6 100755
--- a/configure
+++ b/configure
@@ -1532,7 +1532,9 @@ EOF
:
else
error_exit zlib check failed \
-Make sure
This just makes it a tiny bit easier for new developers to get started
by making it easy to see what package they need to install to get
the dependency.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
configure | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff
Hi Steward,
Am 23.01.2014 05:54, schrieb Stewart Smith:
This just makes it a tiny bit easier for new developers to get started
by making it easy to see what package they need to install to get
the dependency.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
configure | 12
The -fstack-protector flag family is useful for ensuring safety and for
debugging, but has a performance impact. Here are some boot time comparisons of
the various versions of -fstack-protector using qemu-system-arm on an x86_64
host:
# -fstack-protector-all
Startup finished in 1.810s
Hi,
please see comments below.
Am 13.01.2014 21:00, schrieb Steven Noonan:
The -fstack-protector flag family is useful for ensuring safety and for
debugging, but has a performance impact. Here are some boot time comparisons
of
the various versions of -fstack-protector using qemu-system-arm
In the new form most lines of the code now look like the final output:
there is no leading echo command and the lines are shorter.
The resulting output is nearly identical: the only difference is a blank
character which was deliberately removed:
@@ -8,7 +8,7 @@
--interp-prefix=PREFIX where
The help message uses $python and displays its value, so that macro
should be tested and set early.
With this modification, configure --help displays the correct value
(usually python -B) and no longer creates several *.pyc files.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
There still
On Wed, Nov 27, 2013 at 6:12 PM, Antony Pavlov antonynpav...@gmail.com wrote:
The word DTC (device tree compiler) sometimes
sounds ambiguous.
DTC not present sounds like dt compiler
not present but QEMU does not need the dt compiler
itself but only libfdt library from DTC distribution.
The
$config_host_mak
fi
echo CC_I386=$cc_i386 $config_host_mak
I tried to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign of IASL
-if $iasl -h /dev/null 21; then
+if test $iasl $iasl -h /dev/null 21; then
echo IASL=$iasl $config_host_mak
fi
echo CC_I386=$cc_i386 $config_host_mak
I tried to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl
Am 25.11.2013 14:54, schrieb Marcel Apfelbaum:
On Mon, 2013-11-25 at 13:26 +0200, Michael S. Tsirkin wrote:
On Sun, Nov 24, 2013 at 09:58:34PM +0100, Stefan Weil wrote:
--iasl=false works without further modifications (because test false
-h works and returns false). It also looks more natural
commit bdf523e6923f1e667055e947e71fc600549cefae
configure: Add config.status to recreate the current configuration
moved current configure flags to config.status
This makes sense, but this makes it harder to bisect problems that
trigger with a specific set of flags only, since old configure
--iasl option was added to CC option parsing section by mistake,
it's not effective there and attempts to use cause
an 'unknown option' error.
Fix this up.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Useful for platforms with a broken IASL.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 0592ba7..d0a0abe 100755
--- a/configure
+++ b/configure
@@ -1080,6 +1080,7 @@ echo
Am 24.11.2013 10:37, schrieb Michael S. Tsirkin:
commit bdf523e6923f1e667055e947e71fc600549cefae
configure: Add config.status to recreate the current configuration
moved current configure flags to config.status
This makes sense, but this makes it harder to bisect problems that
trigger
On Sun, 2013-11-24 at 11:52 +0200, Michael S. Tsirkin wrote:
--iasl option was added to CC option parsing section by mistake,
it's not effective there and attempts to use cause
an 'unknown option' error.
Fix this up.
Now it works...
Tested-by: Marcel Apfelbaum marce...@redhat.com
without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign of IASL in config-host.mak)
I think this is because the prev test $iasl -h /dev/null 21
fails of course.
I don't get
=$iasl $config_host_mak
fi
echo CC_I386=$cc_i386 $config_host_mak
I tried to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign of IASL
; then
echo IASL=$iasl $config_host_mak
fi
echo CC_I386=$cc_i386 $config_host_mak
I tried to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign
$config_host_mak
-if $iasl -h /dev/null 21; then
+if test $iasl $iasl -h /dev/null 21; then
echo IASL=$iasl $config_host_mak
fi
echo CC_I386=$cc_i386 $config_host_mak
I tried to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure
to disable iasl without this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign of IASL in config-host.mak)
I think this is because the prev test $iasl -h /dev/null
this patch and it worked for me...
I used:
- [Qemu-devel] [PATCH] configure: make --iasl option actually work
- ./configure --iasl= (or --iasl=)
and it worked (no sign of IASL in config-host.mak)
I think this is because the prev test $iasl -h /dev/null 21
fails of course.
By luck
601 - 700 of 1161 matches
Mail list logo
