* [PATCH for-4.8 0/3] libacpi fixes
@ 2016-10-14 17:02 Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw)
To: Xen-devel; +Cc: Wei Liu
Wei Liu (3):
libacpi: fix arm64 build
libacpi: require ACPI_BUILD_DIR to be set
libacpi: add back the "G" in "GNU" in licence header
tools/libacpi/Makefile | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu
@ 2016-10-14 17:02 ` Wei Liu
2016-10-17 10:47 ` Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw)
To: Xen-devel
Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Boris Ostrovsky
The arm64 build for libacpi was broken due to two reasons:
1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
made CONFIG_ARM disappear.
Fix those by:
1. Correctly generate full path for dsdt_anaycpu_arm.c.
2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
on settings in firmware/Rules.mk.
While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
accurate.
Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Julien Grall <julien.grall@arm.com>
Cc: Wei Chen <wei.chen@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Stefano Stebellini <sstabellini@kernel.org>
Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
on arm64.
Would appreciate any build test report from ARM people.
---
tools/libacpi/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index db7a3a9..24eb0c2 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -13,12 +13,12 @@
#
XEN_ROOT = $(CURDIR)/../..
-include $(XEN_ROOT)/tools/firmware/Rules.mk
+include $(XEN_ROOT)/tools/Rules.mk
MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
+C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c
C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h)
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set
2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
@ 2016-10-14 17:02 ` Wei Liu
2016-10-24 12:48 ` Jan Beulich
2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu
2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper
3 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw)
To: Xen-devel; +Cc: Wei Liu, Jan Beulich
It's better to have a explicit error than a build failure returned by
gcc.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Jan Beulich <JBeulich@suse.com>
---
tools/libacpi/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 24eb0c2..c1f0af8 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -15,6 +15,10 @@
XEN_ROOT = $(CURDIR)/../..
include $(XEN_ROOT)/tools/Rules.mk
+ifeq ($(ACPI_BUILD_DIR),)
+$(error ACPI_BUILD_DIR not set)
+endif
+
MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header
2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu
@ 2016-10-14 17:02 ` Wei Liu
2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper
3 siblings, 0 replies; 14+ messages in thread
From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw)
To: Xen-devel; +Cc: Wei Liu, Jan Beulich
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Jan Beulich <JBeulich@suse.com>
---
tools/libacpi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index c1f0af8..18a5cd4 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -9,7 +9,7 @@
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# NU Lesser General Public License for more details.
+# GNU Lesser General Public License for more details.
#
XEN_ROOT = $(CURDIR)/../..
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 0/3] libacpi fixes
2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu
` (2 preceding siblings ...)
2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu
@ 2016-10-14 17:19 ` Andrew Cooper
3 siblings, 0 replies; 14+ messages in thread
From: Andrew Cooper @ 2016-10-14 17:19 UTC (permalink / raw)
To: Wei Liu, Xen-devel
On 14/10/16 18:02, Wei Liu wrote:
> Wei Liu (3):
> libacpi: fix arm64 build
> libacpi: require ACPI_BUILD_DIR to be set
> libacpi: add back the "G" in "GNU" in licence header
All Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
@ 2016-10-17 10:47 ` Wei Liu
2016-10-17 14:57 ` Steve Capper
0 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2016-10-17 10:47 UTC (permalink / raw)
To: Xen-devel
Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Boris Ostrovsky
On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> The arm64 build for libacpi was broken due to two reasons:
>
> 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> made CONFIG_ARM disappear.
>
> Fix those by:
>
> 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> on settings in firmware/Rules.mk.
>
> While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> accurate.
>
> Reported-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Wei Chen <wei.chen@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> Cc: Stefano Stebellini <sstabellini@kernel.org>
>
> Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> on arm64.
>
> Would appreciate any build test report from ARM people.
I set up a chroot environment this morning and built arm64 Xen. It
worked.
Since Jan and Julien are both away, I've taken the liberty of applying
this patch with both my RM hat and tools maintainer hat on.
I have also applied patch #3 since it is rather trivial.
I will let Jan decide whether patch #2 is necessary.
Wei.
> ---
> tools/libacpi/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> index db7a3a9..24eb0c2 100644
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -13,12 +13,12 @@
> #
>
> XEN_ROOT = $(CURDIR)/../..
> -include $(XEN_ROOT)/tools/firmware/Rules.mk
> +include $(XEN_ROOT)/tools/Rules.mk
>
> MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>
> C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
> -C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
> +C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c
> C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
> H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h)
>
> --
> 2.1.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-17 10:47 ` Wei Liu
@ 2016-10-17 14:57 ` Steve Capper
2016-10-17 16:55 ` Wei Liu
0 siblings, 1 reply; 14+ messages in thread
From: Steve Capper @ 2016-10-17 14:57 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stebellini, Wei Chen, Steve Capper, Julien Grall,
Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky
On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > The arm64 build for libacpi was broken due to two reasons:
> >
> > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > made CONFIG_ARM disappear.
> >
> > Fix those by:
> >
> > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > on settings in firmware/Rules.mk.
> >
> > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > accurate.
> >
> > Reported-by: Julien Grall <julien.grall@arm.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > Cc: Julien Grall <julien.grall@arm.com>
> > Cc: Wei Chen <wei.chen@arm.com>
> > Cc: Steve Capper <steve.capper@arm.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> > Cc: Stefano Stebellini <sstabellini@kernel.org>
> >
> > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > on arm64.
> >
> > Would appreciate any build test report from ARM people.
>
> I set up a chroot environment this morning and built arm64 Xen. It
> worked.
>
> Since Jan and Julien are both away, I've taken the liberty of applying
> this patch with both my RM hat and tools maintainer hat on.
>
> I have also applied patch #3 since it is rather trivial.
>
> I will let Jan decide whether patch #2 is necessary.
>
Thanks Wei,
I am trying to verify this patch, but I think I am running into another
issue with the libxl acpi support patches.
Essentially I'm getting namespace clashes with the following:
* nonnull
* noreturn
* register_t
I think this is due to the following logic in the libxl/Makefile:
libxl_arm_acpi.o: libxl_arm_acpi.c
$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
then eventually pulls in xen/include/xen/compiler.h which redefines key
information.
Which rootfs are you chrooting into for the testing?
(I've experienced build issues on Debian Jessie and Ubuntu Xenial running
in a Docker container).
Cheers,
--
Steve
I build Xen via:
$ git clean -f -d -x
$ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64
$ make
My builds finish like this:
gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c
In file included from /usr/include/linux/types.h:4:0,
from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
from /usr/include/signal.h:332,
from libxl_internal.h:30,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
typedef u64 register_t;
^
In file included from /usr/include/uuid/uuid.h:38:0,
from libxl_osdeps.h:43,
from libxl_internal.h:20,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/aarch64-linux-gnu/sys/types.h:205:13: note: previous declaration of 'register_t' was here
typedef int register_t __attribute__ ((__mode__ (__word__)));
^
In file included from libxl_internal.h:35:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/stdlib.h:241:6: error: nonnull argument has invalid operand number (argument 1)
__locale_t __loc) __THROW __nonnull ((1, 4));
^
/usr/include/stdlib.h:246:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 4));
^
/usr/include/stdlib.h:252:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 4));
^
/usr/include/stdlib.h:258:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 4));
^
/usr/include/stdlib.h:262:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 3));
^
/usr/include/stdlib.h:266:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 3));
^
/usr/include/stdlib.h:271:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 3));
^
/usr/include/stdlib.h:355:8: error: nonnull argument has invalid operand number (argument 1)
int32_t *__restrict __result) __THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:363:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 4));
^
/usr/include/stdlib.h:367:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:424:9: error: nonnull argument has invalid operand number (argument 1)
double *__restrict __result) __THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:427:9: error: nonnull argument has invalid operand number (argument 1)
double *__restrict __result) __THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:432:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:436:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:441:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:445:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:452:15: error: nonnull argument has invalid operand number (argument 1)
struct drand48_data *__buffer) __THROW __nonnull ((1, 2));
^
/usr/include/stdlib.h:456:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
In file included from libxl_internal.h:35:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/stdlib.h:757:6: error: nonnull argument has invalid operand number (argument 1)
__nonnull ((1, 2, 5)) __wur;
^
/usr/include/stdlib.h:766:6: error: nonnull argument has invalid operand number (argument 1)
__compar_fn_t __compar) __nonnull ((1, 4));
^
/usr/include/stdlib.h:770:3: error: nonnull argument has invalid operand number (argument 1)
__nonnull ((1, 4));
^
/usr/include/stdlib.h:813:6: error: nonnull argument has invalid operand number (argument 1)
int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur;
^
/usr/include/stdlib.h:819:6: error: nonnull argument has invalid operand number (argument 1)
int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur;
^
/usr/include/stdlib.h:832:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4)) __wur;
^
/usr/include/stdlib.h:835:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4)) __wur;
^
/usr/include/stdlib.h:844:6: error: nonnull argument has invalid operand number (argument 1)
size_t __len) __THROW __nonnull ((3, 4, 5));
^
/usr/include/stdlib.h:847:6: error: nonnull argument has invalid operand number (argument 1)
size_t __len) __THROW __nonnull ((3, 4, 5));
^
/usr/include/stdlib.h:852:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4, 5));
^
/usr/include/stdlib.h:856:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4, 5));
^
/usr/include/stdlib.h:902:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2, 3)) __wur;
^
In file included from libxl_internal.h:36:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/string.h:47:8: error: nonnull argument has invalid operand number (argument 1)
size_t __n) __THROW __nonnull ((1, 2));
^
/usr/include/string.h:51:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:60:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:70:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:130:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:134:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:138:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:141:9: error: nonnull argument has invalid operand number (argument 1)
size_t __n) __THROW __nonnull ((1, 2));
^
/usr/include/string.h:145:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:148:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:152:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:167:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2, 3));
^
/usr/include/string.h:170:5: error: nonnull argument has invalid operand number (argument 1)
__locale_t __l) __THROW __nonnull ((2, 4));
^
/usr/include/string.h:286:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:290:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:316:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:343:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:357:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 3));
^
/usr/include/string.h:361:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 3));
^
/usr/include/string.h:374:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:384:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 3));
^
/usr/include/string.h:390:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:393:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:456:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:463:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:535:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:539:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
/usr/include/string.h:547:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2, 3));
^
/usr/include/string.h:551:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2, 4));
^
/usr/include/string.h:559:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:568:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:570:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:576:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:579:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/string.h:585:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __attribute_pure__ __nonnull ((1, 2));
^
In file included from libxl_internal.h:37:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/unistd.h:552:6: error: nonnull argument has invalid operand number (argument 1)
char *const __envp[]) __THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:564:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:569:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:574:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:579:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:585:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:592:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
In file included from libxl_internal.h:37:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/unistd.h:791:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2)) __wur;
^
/usr/include/unistd.h:798:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 4)) __wur;
^
/usr/include/unistd.h:804:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2)) __wur;
^
/usr/include/unistd.h:811:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2)) __wur;
^
/usr/include/unistd.h:817:9: error: nonnull argument has invalid operand number (argument 1)
const char *__to) __THROW __nonnull ((1, 3)) __wur;
^
/usr/include/unistd.h:822:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 3)) __wur;
^
In file included from libxl_internal.h:37:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/unistd.h:1121:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/unistd.h:1134:5: error: nonnull argument has invalid operand number (argument 1)
ssize_t __n) __THROW __nonnull ((1, 2));
^
In file included from libxl_internal.h:43:0,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
/usr/include/aarch64-linux-gnu/sys/stat.h:210:11: error: nonnull argument has invalid operand number (argument 1)
struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:229:13: error: nonnull argument has invalid operand number (argument 1)
struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:240:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:255:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:264:12: error: nonnull argument has invalid operand number (argument 1)
struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:278:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((1, 2));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:402:14: error: nonnull argument has invalid operand number (argument 1)
struct stat *__stat_buf) __THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:404:15: error: nonnull argument has invalid operand number (argument 1)
struct stat *__stat_buf) __THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:407:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:435:16: error: nonnull argument has invalid operand number (argument 1)
struct stat64 *__stat_buf) __THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:437:17: error: nonnull argument has invalid operand number (argument 1)
struct stat64 *__stat_buf) __THROW __nonnull ((2, 3));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:440:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 4));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:443:8: error: nonnull argument has invalid operand number (argument 1)
__dev_t *__dev) __THROW __nonnull ((2, 4));
^
/usr/include/aarch64-linux-gnu/sys/stat.h:447:6: error: nonnull argument has invalid operand number (argument 1)
__THROW __nonnull ((3, 5));
^
In file included from ../../xen/include/xen/config.h:13:0,
from ../../xen/include/asm/types.h:6,
from /usr/include/linux/types.h:4,
from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
from /usr/include/signal.h:332,
from libxl_internal.h:30,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
libxl_internal.h:202:68: error: expected ')' before '__attribute__'
size_t nmemb, size_t size) __attribute__((noreturn));
^
In file included from libxl_arm.h:17:0,
from libxl_arm_acpi.c:19:
libxl_internal.h:202:77: error: expected ',' or ';' before ')' token
size_t nmemb, size_t size) __attribute__((noreturn));
^
In file included from ../../xen/include/xen/config.h:13:0,
from ../../xen/include/asm/types.h:6,
from /usr/include/linux/types.h:4,
from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
from /usr/include/signal.h:332,
from libxl_internal.h:30,
from libxl_arm.h:17,
from libxl_arm_acpi.c:19:
libxl_internal.h:1618:61: error: expected ')' before '__attribute__'
char *const env[]) __attribute__((noreturn));
^
In file included from libxl_arm.h:17:0,
from libxl_arm_acpi.c:19:
libxl_internal.h:1618:70: error: expected ',' or ';' before ')' token
char *const env[]) __attribute__((noreturn));
^
Makefile:99: recipe for target 'libxl_arm_acpi.o' failed
make[3]: *** [libxl_arm_acpi.o] Error 1
make[3]: Leaving directory '/home/steven/xen/tools/libxl'
/home/steven/xen/tools/../tools/Rules.mk:216: recipe for target 'subdir-install-libxl' failed
make[2]: *** [subdir-install-libxl] Error 2
make[2]: Leaving directory '/home/steven/xen/tools'
/home/steven/xen/tools/../tools/Rules.mk:211: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/home/steven/xen/tools'
Makefile:101: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-17 14:57 ` Steve Capper
@ 2016-10-17 16:55 ` Wei Liu
2016-10-17 23:36 ` Stefano Stabellini
0 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2016-10-17 16:55 UTC (permalink / raw)
To: Steve Capper
Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel,
Boris Ostrovsky
On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > The arm64 build for libacpi was broken due to two reasons:
> > >
> > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > > made CONFIG_ARM disappear.
> > >
> > > Fix those by:
> > >
> > > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > > on settings in firmware/Rules.mk.
> > >
> > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > > accurate.
> > >
> > > Reported-by: Julien Grall <julien.grall@arm.com>
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > > Cc: Julien Grall <julien.grall@arm.com>
> > > Cc: Wei Chen <wei.chen@arm.com>
> > > Cc: Steve Capper <steve.capper@arm.com>
> > > Cc: Jan Beulich <JBeulich@suse.com>
> > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > > Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> > > Cc: Stefano Stebellini <sstabellini@kernel.org>
> > >
> > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > > on arm64.
> > >
> > > Would appreciate any build test report from ARM people.
> >
> > I set up a chroot environment this morning and built arm64 Xen. It
> > worked.
> >
> > Since Jan and Julien are both away, I've taken the liberty of applying
> > this patch with both my RM hat and tools maintainer hat on.
> >
> > I have also applied patch #3 since it is rather trivial.
> >
> > I will let Jan decide whether patch #2 is necessary.
> >
>
> Thanks Wei,
> I am trying to verify this patch, but I think I am running into another
> issue with the libxl acpi support patches.
>
> Essentially I'm getting namespace clashes with the following:
> * nonnull
> * noreturn
> * register_t
>
> I think this is due to the following logic in the libxl/Makefile:
> libxl_arm_acpi.o: libxl_arm_acpi.c
> $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>
> When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
> in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
> then eventually pulls in xen/include/xen/compiler.h which redefines key
> information.
>
> Which rootfs are you chrooting into for the testing?
> (I've experienced build issues on Debian Jessie and Ubuntu Xenial running
> in a Docker container).
>
qemu-debootstrap, sid, arm64.
I saw similar errors. But they went away after I `git clean -fffddddxx`
the tree.
The fact that they went away somehow and Julien succeeded in building on
variant of this patch made me think it was due to some issues in my
environment.
> Cheers,
> --
> Steve
>
> I build Xen via:
> $ git clean -f -d -x
> $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64
> $ make
>
> My builds finish like this:
>
> gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c
> In file included from /usr/include/linux/types.h:4:0,
> from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> from /usr/include/signal.h:332,
> from libxl_internal.h:30,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
> typedef u64 register_t;
> ^
Now that I think about this, we indeed had similar error in the past.
But I'm curious why I succeeded.
┌─[wei@zion] - [/local/work/xen-arm64.git/tools/libxl] - [Mon Oct 17, 17:53]
└─[$]> ls -l libxl_arm_acpi.o
-rw-rw-r-- 1 wei wei 535160 Oct 17 11:37 libxl_arm_acpi.o
┌─[wei@zion] - [/local/work/xen-arm64.git/tools/libxl] - [Mon Oct 17, 17:53]
└─[$]> file libxl_arm_acpi.o
libxl_arm_acpi.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped
> In file included from /usr/include/uuid/uuid.h:38:0,
> from libxl_osdeps.h:43,
> from libxl_internal.h:20,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/aarch64-linux-gnu/sys/types.h:205:13: note: previous declaration of 'register_t' was here
> typedef int register_t __attribute__ ((__mode__ (__word__)));
> ^
> In file included from libxl_internal.h:35:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/stdlib.h:241:6: error: nonnull argument has invalid operand number (argument 1)
> __locale_t __loc) __THROW __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:246:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:252:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:258:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:262:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 3));
> ^
> /usr/include/stdlib.h:266:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 3));
> ^
> /usr/include/stdlib.h:271:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 3));
> ^
> /usr/include/stdlib.h:355:8: error: nonnull argument has invalid operand number (argument 1)
> int32_t *__restrict __result) __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:363:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 4));
> ^
> /usr/include/stdlib.h:367:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:424:9: error: nonnull argument has invalid operand number (argument 1)
> double *__restrict __result) __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:427:9: error: nonnull argument has invalid operand number (argument 1)
> double *__restrict __result) __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:432:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:436:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:441:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:445:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:452:15: error: nonnull argument has invalid operand number (argument 1)
> struct drand48_data *__buffer) __THROW __nonnull ((1, 2));
> ^
> /usr/include/stdlib.h:456:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> In file included from libxl_internal.h:35:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/stdlib.h:757:6: error: nonnull argument has invalid operand number (argument 1)
> __nonnull ((1, 2, 5)) __wur;
> ^
> /usr/include/stdlib.h:766:6: error: nonnull argument has invalid operand number (argument 1)
> __compar_fn_t __compar) __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:770:3: error: nonnull argument has invalid operand number (argument 1)
> __nonnull ((1, 4));
> ^
> /usr/include/stdlib.h:813:6: error: nonnull argument has invalid operand number (argument 1)
> int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur;
> ^
> /usr/include/stdlib.h:819:6: error: nonnull argument has invalid operand number (argument 1)
> int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur;
> ^
> /usr/include/stdlib.h:832:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4)) __wur;
> ^
> /usr/include/stdlib.h:835:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4)) __wur;
> ^
> /usr/include/stdlib.h:844:6: error: nonnull argument has invalid operand number (argument 1)
> size_t __len) __THROW __nonnull ((3, 4, 5));
> ^
> /usr/include/stdlib.h:847:6: error: nonnull argument has invalid operand number (argument 1)
> size_t __len) __THROW __nonnull ((3, 4, 5));
> ^
> /usr/include/stdlib.h:852:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4, 5));
> ^
> /usr/include/stdlib.h:856:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4, 5));
> ^
> /usr/include/stdlib.h:902:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2, 3)) __wur;
> ^
> In file included from libxl_internal.h:36:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/string.h:47:8: error: nonnull argument has invalid operand number (argument 1)
> size_t __n) __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:51:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:60:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:70:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:130:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:134:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:138:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:141:9: error: nonnull argument has invalid operand number (argument 1)
> size_t __n) __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:145:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:148:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:152:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:167:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2, 3));
> ^
> /usr/include/string.h:170:5: error: nonnull argument has invalid operand number (argument 1)
> __locale_t __l) __THROW __nonnull ((2, 4));
> ^
> /usr/include/string.h:286:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:290:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:316:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:343:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:357:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 3));
> ^
> /usr/include/string.h:361:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 3));
> ^
> /usr/include/string.h:374:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:384:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 3));
> ^
> /usr/include/string.h:390:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:393:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:456:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:463:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:535:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:539:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> /usr/include/string.h:547:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2, 3));
> ^
> /usr/include/string.h:551:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2, 4));
> ^
> /usr/include/string.h:559:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:568:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:570:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:576:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:579:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/string.h:585:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __attribute_pure__ __nonnull ((1, 2));
> ^
> In file included from libxl_internal.h:37:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/unistd.h:552:6: error: nonnull argument has invalid operand number (argument 1)
> char *const __envp[]) __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:564:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:569:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:574:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:579:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:585:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:592:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> In file included from libxl_internal.h:37:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/unistd.h:791:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2)) __wur;
> ^
> /usr/include/unistd.h:798:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 4)) __wur;
> ^
> /usr/include/unistd.h:804:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2)) __wur;
> ^
> /usr/include/unistd.h:811:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2)) __wur;
> ^
> /usr/include/unistd.h:817:9: error: nonnull argument has invalid operand number (argument 1)
> const char *__to) __THROW __nonnull ((1, 3)) __wur;
> ^
> /usr/include/unistd.h:822:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 3)) __wur;
> ^
> In file included from libxl_internal.h:37:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/unistd.h:1121:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/unistd.h:1134:5: error: nonnull argument has invalid operand number (argument 1)
> ssize_t __n) __THROW __nonnull ((1, 2));
> ^
> In file included from libxl_internal.h:43:0,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> /usr/include/aarch64-linux-gnu/sys/stat.h:210:11: error: nonnull argument has invalid operand number (argument 1)
> struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:229:13: error: nonnull argument has invalid operand number (argument 1)
> struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:240:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:255:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:264:12: error: nonnull argument has invalid operand number (argument 1)
> struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:278:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((1, 2));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:402:14: error: nonnull argument has invalid operand number (argument 1)
> struct stat *__stat_buf) __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:404:15: error: nonnull argument has invalid operand number (argument 1)
> struct stat *__stat_buf) __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:407:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:435:16: error: nonnull argument has invalid operand number (argument 1)
> struct stat64 *__stat_buf) __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:437:17: error: nonnull argument has invalid operand number (argument 1)
> struct stat64 *__stat_buf) __THROW __nonnull ((2, 3));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:440:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 4));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:443:8: error: nonnull argument has invalid operand number (argument 1)
> __dev_t *__dev) __THROW __nonnull ((2, 4));
> ^
> /usr/include/aarch64-linux-gnu/sys/stat.h:447:6: error: nonnull argument has invalid operand number (argument 1)
> __THROW __nonnull ((3, 5));
> ^
> In file included from ../../xen/include/xen/config.h:13:0,
> from ../../xen/include/asm/types.h:6,
> from /usr/include/linux/types.h:4,
> from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> from /usr/include/signal.h:332,
> from libxl_internal.h:30,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> libxl_internal.h:202:68: error: expected ')' before '__attribute__'
> size_t nmemb, size_t size) __attribute__((noreturn));
> ^
> In file included from libxl_arm.h:17:0,
> from libxl_arm_acpi.c:19:
> libxl_internal.h:202:77: error: expected ',' or ';' before ')' token
> size_t nmemb, size_t size) __attribute__((noreturn));
> ^
> In file included from ../../xen/include/xen/config.h:13:0,
> from ../../xen/include/asm/types.h:6,
> from /usr/include/linux/types.h:4,
> from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> from /usr/include/signal.h:332,
> from libxl_internal.h:30,
> from libxl_arm.h:17,
> from libxl_arm_acpi.c:19:
> libxl_internal.h:1618:61: error: expected ')' before '__attribute__'
> char *const env[]) __attribute__((noreturn));
> ^
> In file included from libxl_arm.h:17:0,
> from libxl_arm_acpi.c:19:
> libxl_internal.h:1618:70: error: expected ',' or ';' before ')' token
> char *const env[]) __attribute__((noreturn));
> ^
> Makefile:99: recipe for target 'libxl_arm_acpi.o' failed
> make[3]: *** [libxl_arm_acpi.o] Error 1
> make[3]: Leaving directory '/home/steven/xen/tools/libxl'
> /home/steven/xen/tools/../tools/Rules.mk:216: recipe for target 'subdir-install-libxl' failed
> make[2]: *** [subdir-install-libxl] Error 2
> make[2]: Leaving directory '/home/steven/xen/tools'
> /home/steven/xen/tools/../tools/Rules.mk:211: recipe for target 'subdirs-install' failed
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory '/home/steven/xen/tools'
> Makefile:101: recipe for target 'install-tools' failed
> make: *** [install-tools] Error 2
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-17 16:55 ` Wei Liu
@ 2016-10-17 23:36 ` Stefano Stabellini
2016-10-18 7:52 ` Steve Capper
2016-10-18 11:17 ` Wei Liu
0 siblings, 2 replies; 14+ messages in thread
From: Stefano Stabellini @ 2016-10-17 23:36 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stebellini, Steve Capper, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel,
Boris Ostrovsky
[-- Attachment #1: Type: TEXT/PLAIN, Size: 7647 bytes --]
On Mon, 17 Oct 2016, Wei Liu wrote:
> On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > > The arm64 build for libacpi was broken due to two reasons:
> > > >
> > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > > > made CONFIG_ARM disappear.
> > > >
> > > > Fix those by:
> > > >
> > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > > > on settings in firmware/Rules.mk.
> > > >
> > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > > > accurate.
> > > >
> > > > Reported-by: Julien Grall <julien.grall@arm.com>
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > > Cc: Julien Grall <julien.grall@arm.com>
> > > > Cc: Wei Chen <wei.chen@arm.com>
> > > > Cc: Steve Capper <steve.capper@arm.com>
> > > > Cc: Jan Beulich <JBeulich@suse.com>
> > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > > > Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> > > > Cc: Stefano Stebellini <sstabellini@kernel.org>
> > > >
> > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > > > on arm64.
> > > >
> > > > Would appreciate any build test report from ARM people.
> > >
> > > I set up a chroot environment this morning and built arm64 Xen. It
> > > worked.
> > >
> > > Since Jan and Julien are both away, I've taken the liberty of applying
> > > this patch with both my RM hat and tools maintainer hat on.
> > >
> > > I have also applied patch #3 since it is rather trivial.
> > >
> > > I will let Jan decide whether patch #2 is necessary.
> > >
> >
> > Thanks Wei,
> > I am trying to verify this patch, but I think I am running into another
> > issue with the libxl acpi support patches.
> >
> > Essentially I'm getting namespace clashes with the following:
> > * nonnull
> > * noreturn
> > * register_t
> >
> > I think this is due to the following logic in the libxl/Makefile:
> > libxl_arm_acpi.o: libxl_arm_acpi.c
> > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> >
> > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
> > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
> > then eventually pulls in xen/include/xen/compiler.h which redefines key
> > information.
> >
> > Which rootfs are you chrooting into for the testing?
> > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running
> > in a Docker container).
> >
>
> qemu-debootstrap, sid, arm64.
>
> I saw similar errors. But they went away after I `git clean -fffddddxx`
> the tree.
>
> The fact that they went away somehow and Julien succeeded in building on
> variant of this patch made me think it was due to some issues in my
> environment.
>
> > Cheers,
> > --
> > Steve
> >
> > I build Xen via:
> > $ git clean -f -d -x
> > $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64
> > $ make
> >
> > My builds finish like this:
> >
> > gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen
/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tool
s/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/
include/ -o libxl_arm_acpi.o libxl_arm_acpi.c
> > In file included from /usr/include/linux/types.h:4:0,
> > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> > from /usr/include/signal.h:332,
> > from libxl_internal.h:30,
> > from libxl_arm.h:17,
> > from libxl_arm_acpi.c:19:
> > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
> > typedef u64 register_t;
> > ^
>
> Now that I think about this, we indeed had similar error in the past.
>
> But I'm curious why I succeeded.
I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9)
fixes the dsdt_anycpu_arm.c build issue.
This error is due to the libxl build picking up
"../../xen/include/asm/types.h" for
#include <asm/types.h>
which is wrong (it should be /usr/include/asm/types.h).
I did some digging and it depends on the build order:
* build tools/ before xen/ --> works
* build xen/ before tools/ --> does not work
The reason for this is that building Xen creates the xen/include/arm
link, which causes ../../xen/include/asm/types.h from being chosen
first, because of -I../../xen/include/ in libxl/Makefile.
This is dangerous and wrong.
---
ARM64: fix libxl build, do not include ../../xen/include
Do not include ../../xen/include/ to build libxl_arm_acpi.c: header
files clashing against default headers under /usr/include are present in
that directory.
Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead.
Build tested on ARM64 and x86_64.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
diff --git a/tools/include/Makefile b/tools/include/Makefile
index dec8b3d..d95d837 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -20,6 +20,7 @@ xen/.dir:
ln -sf ../xen-sys/$(XEN_OS) xen/sys
ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
ln -s ../xen-foreign xen/foreign
+ ln -s $(XEN_ROOT)/xen/include/acpi acpi
touch $@
# Not xen/xsm as that clashes with link to
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index c4e4117..dac19ac 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -96,7 +96,7 @@ dsdt_anycpu_arm.c:
$(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
libxl_arm_acpi.o: libxl_arm_acpi.c
- $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
+ $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c
else
LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
endif
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-17 23:36 ` Stefano Stabellini
@ 2016-10-18 7:52 ` Steve Capper
2016-10-18 11:21 ` Wei Liu
2016-10-18 11:17 ` Wei Liu
1 sibling, 1 reply; 14+ messages in thread
From: Steve Capper @ 2016-10-18 7:52 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich,
Shannon Zhao, Xen-devel, Boris Ostrovsky
On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote:
> On Mon, 17 Oct 2016, Wei Liu wrote:
> > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > > > The arm64 build for libacpi was broken due to two reasons:
> > > > >
[ ... ]
> > > In file included from /usr/include/linux/types.h:4:0,
> > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> > > from /usr/include/signal.h:332,
> > > from libxl_internal.h:30,
> > > from libxl_arm.h:17,
> > > from libxl_arm_acpi.c:19:
> > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
> > > typedef u64 register_t;
> > > ^
> >
> > Now that I think about this, we indeed had similar error in the past.
> >
> > But I'm curious why I succeeded.
>
> I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9)
> fixes the dsdt_anycpu_arm.c build issue.
>
> This error is due to the libxl build picking up
> "../../xen/include/asm/types.h" for
>
> #include <asm/types.h>
>
> which is wrong (it should be /usr/include/asm/types.h).
> I did some digging and it depends on the build order:
>
> * build tools/ before xen/ --> works
> * build xen/ before tools/ --> does not work
>
> The reason for this is that building Xen creates the xen/include/arm
> link, which causes ../../xen/include/asm/types.h from being chosen
> first, because of -I../../xen/include/ in libxl/Makefile.
>
> This is dangerous and wrong.
>
> ---
> ARM64: fix libxl build, do not include ../../xen/include
>
> Do not include ../../xen/include/ to build libxl_arm_acpi.c: header
> files clashing against default headers under /usr/include are present in
> that directory.
>
> Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead.
>
> Build tested on ARM64 and x86_64.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
> diff --git a/tools/include/Makefile b/tools/include/Makefile
> index dec8b3d..d95d837 100644
> --- a/tools/include/Makefile
> +++ b/tools/include/Makefile
> @@ -20,6 +20,7 @@ xen/.dir:
> ln -sf ../xen-sys/$(XEN_OS) xen/sys
> ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
> ln -s ../xen-foreign xen/foreign
> + ln -s $(XEN_ROOT)/xen/include/acpi acpi
> touch $@
>
> # Not xen/xsm as that clashes with link to
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index c4e4117..dac19ac 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c:
> $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
>
> libxl_arm_acpi.o: libxl_arm_acpi.c
> - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c
> else
> LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
> endif
Thanks Stefano,
It hadn't occurred to me to add the acpi symlink :-).
I can confirm that this fix works for me.
( I think we just delete the libxl_arm_acpi.o build rule and rely on
implicit make? )
Cheers,
--
Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-17 23:36 ` Stefano Stabellini
2016-10-18 7:52 ` Steve Capper
@ 2016-10-18 11:17 ` Wei Liu
1 sibling, 0 replies; 14+ messages in thread
From: Wei Liu @ 2016-10-18 11:17 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Steve Capper, Wei Chen, Steve Capper, Shannon Zhao, Julien Grall,
Jan Beulich, Xen-devel, Wei Liu, Boris Ostrovsky
On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote:
> On Mon, 17 Oct 2016, Wei Liu wrote:
> > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > > > The arm64 build for libacpi was broken due to two reasons:
> > > > >
> > > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > > > > made CONFIG_ARM disappear.
> > > > >
> > > > > Fix those by:
> > > > >
> > > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > > > > on settings in firmware/Rules.mk.
> > > > >
> > > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > > > > accurate.
> > > > >
> > > > > Reported-by: Julien Grall <julien.grall@arm.com>
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > ---
> > > > > Cc: Julien Grall <julien.grall@arm.com>
> > > > > Cc: Wei Chen <wei.chen@arm.com>
> > > > > Cc: Steve Capper <steve.capper@arm.com>
> > > > > Cc: Jan Beulich <JBeulich@suse.com>
> > > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > > > > Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> > > > > Cc: Stefano Stebellini <sstabellini@kernel.org>
> > > > >
> > > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > > > > on arm64.
> > > > >
> > > > > Would appreciate any build test report from ARM people.
> > > >
> > > > I set up a chroot environment this morning and built arm64 Xen. It
> > > > worked.
> > > >
> > > > Since Jan and Julien are both away, I've taken the liberty of applying
> > > > this patch with both my RM hat and tools maintainer hat on.
> > > >
> > > > I have also applied patch #3 since it is rather trivial.
> > > >
> > > > I will let Jan decide whether patch #2 is necessary.
> > > >
> > >
> > > Thanks Wei,
> > > I am trying to verify this patch, but I think I am running into another
> > > issue with the libxl acpi support patches.
> > >
> > > Essentially I'm getting namespace clashes with the following:
> > > * nonnull
> > > * noreturn
> > > * register_t
> > >
> > > I think this is due to the following logic in the libxl/Makefile:
> > > libxl_arm_acpi.o: libxl_arm_acpi.c
> > > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> > >
> > > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
> > > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
> > > then eventually pulls in xen/include/xen/compiler.h which redefines key
> > > information.
> > >
> > > Which rootfs are you chrooting into for the testing?
> > > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running
> > > in a Docker container).
> > >
> >
> > qemu-debootstrap, sid, arm64.
> >
> > I saw similar errors. But they went away after I `git clean -fffddddxx`
> > the tree.
> >
> > The fact that they went away somehow and Julien succeeded in building on
> > variant of this patch made me think it was due to some issues in my
> > environment.
> >
> > > Cheers,
> > > --
> > > Steve
> > >
> > > I build Xen via:
> > > $ git clean -f -d -x
> > > $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64
> > > $ make
> > >
> > > My builds finish like this:
> > >
> > > gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tool
> s/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c
> > > In file included from /usr/include/linux/types.h:4:0,
> > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> > > from /usr/include/signal.h:332,
> > > from libxl_internal.h:30,
> > > from libxl_arm.h:17,
> > > from libxl_arm_acpi.c:19:
> > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
> > > typedef u64 register_t;
> > > ^
> >
> > Now that I think about this, we indeed had similar error in the past.
> >
> > But I'm curious why I succeeded.
>
> I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9)
> fixes the dsdt_anycpu_arm.c build issue.
>
> This error is due to the libxl build picking up
> "../../xen/include/asm/types.h" for
>
> #include <asm/types.h>
>
> which is wrong (it should be /usr/include/asm/types.h).
> I did some digging and it depends on the build order:
>
> * build tools/ before xen/ --> works
> * build xen/ before tools/ --> does not work
>
> The reason for this is that building Xen creates the xen/include/arm
> link, which causes ../../xen/include/asm/types.h from being chosen
> first, because of -I../../xen/include/ in libxl/Makefile.
>
Ah, thanks for digging into this.
> This is dangerous and wrong.
Yes, I agree. This should be fixed.
>
> ---
> ARM64: fix libxl build, do not include ../../xen/include
>
> Do not include ../../xen/include/ to build libxl_arm_acpi.c: header
> files clashing against default headers under /usr/include are present in
> that directory.
>
> Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead.
>
> Build tested on ARM64 and x86_64.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Thanks for the patch. This is indeed how it should have been done in the
first place. Sorry for not paying enough attention to this while
reviewing.
> diff --git a/tools/include/Makefile b/tools/include/Makefile
> index dec8b3d..d95d837 100644
> --- a/tools/include/Makefile
> +++ b/tools/include/Makefile
> @@ -20,6 +20,7 @@ xen/.dir:
> ln -sf ../xen-sys/$(XEN_OS) xen/sys
> ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
> ln -s ../xen-foreign xen/foreign
> + ln -s $(XEN_ROOT)/xen/include/acpi acpi
> touch $@
>
> # Not xen/xsm as that clashes with link to
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index c4e4117..dac19ac 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c:
> $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
>
> libxl_arm_acpi.o: libxl_arm_acpi.c
> - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c
> else
> LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
> endif
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-18 7:52 ` Steve Capper
@ 2016-10-18 11:21 ` Wei Liu
2016-10-18 11:43 ` Wei Liu
0 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2016-10-18 11:21 UTC (permalink / raw)
To: Steve Capper
Cc: Stefano Stabellini, Wei Liu, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel,
Boris Ostrovsky
On Tue, Oct 18, 2016 at 08:52:24AM +0100, Steve Capper wrote:
> On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote:
> > On Mon, 17 Oct 2016, Wei Liu wrote:
> > > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> > > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > > > > The arm64 build for libacpi was broken due to two reasons:
> > > > > >
>
> [ ... ]
>
> > > > In file included from /usr/include/linux/types.h:4:0,
> > > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
> > > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
> > > > from /usr/include/signal.h:332,
> > > > from libxl_internal.h:30,
> > > > from libxl_arm.h:17,
> > > > from libxl_arm_acpi.c:19:
> > > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
> > > > typedef u64 register_t;
> > > > ^
> > >
> > > Now that I think about this, we indeed had similar error in the past.
> > >
> > > But I'm curious why I succeeded.
> >
> > I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9)
> > fixes the dsdt_anycpu_arm.c build issue.
> >
> > This error is due to the libxl build picking up
> > "../../xen/include/asm/types.h" for
> >
> > #include <asm/types.h>
> >
> > which is wrong (it should be /usr/include/asm/types.h).
> > I did some digging and it depends on the build order:
> >
> > * build tools/ before xen/ --> works
> > * build xen/ before tools/ --> does not work
> >
> > The reason for this is that building Xen creates the xen/include/arm
> > link, which causes ../../xen/include/asm/types.h from being chosen
> > first, because of -I../../xen/include/ in libxl/Makefile.
> >
> > This is dangerous and wrong.
> >
> > ---
> > ARM64: fix libxl build, do not include ../../xen/include
> >
> > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header
> > files clashing against default headers under /usr/include are present in
> > that directory.
> >
> > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead.
> >
> > Build tested on ARM64 and x86_64.
> >
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> >
> > diff --git a/tools/include/Makefile b/tools/include/Makefile
> > index dec8b3d..d95d837 100644
> > --- a/tools/include/Makefile
> > +++ b/tools/include/Makefile
> > @@ -20,6 +20,7 @@ xen/.dir:
> > ln -sf ../xen-sys/$(XEN_OS) xen/sys
> > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
> > ln -s ../xen-foreign xen/foreign
> > + ln -s $(XEN_ROOT)/xen/include/acpi acpi
> > touch $@
> >
> > # Not xen/xsm as that clashes with link to
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index c4e4117..dac19ac 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c:
> > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
> >
> > libxl_arm_acpi.o: libxl_arm_acpi.c
> > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c
> > else
> > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
> > endif
>
> Thanks Stefano,
> It hadn't occurred to me to add the acpi symlink :-).
>
> I can confirm that this fix works for me.
>
Right. I will turn this into a Tested-by tag. Thanks for testing.
> ( I think we just delete the libxl_arm_acpi.o build rule and rely on
> implicit make? )
>
Yes, that can be done. Patch is welcome. :-)
Wei.
> Cheers,
> --
> Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build
2016-10-18 11:21 ` Wei Liu
@ 2016-10-18 11:43 ` Wei Liu
0 siblings, 0 replies; 14+ messages in thread
From: Wei Liu @ 2016-10-18 11:43 UTC (permalink / raw)
To: Steve Capper
Cc: Stefano Stabellini, Wei Liu, Wei Chen, Steve Capper,
Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel,
Boris Ostrovsky
On Tue, Oct 18, 2016 at 12:21:02PM +0100, Wei Liu wrote:
[...]
> > > ---
> > > ARM64: fix libxl build, do not include ../../xen/include
> > >
> > > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header
> > > files clashing against default headers under /usr/include are present in
> > > that directory.
> > >
> > > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead.
> > >
> > > Build tested on ARM64 and x86_64.
> > >
> > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > >
> > > diff --git a/tools/include/Makefile b/tools/include/Makefile
> > > index dec8b3d..d95d837 100644
> > > --- a/tools/include/Makefile
> > > +++ b/tools/include/Makefile
> > > @@ -20,6 +20,7 @@ xen/.dir:
> > > ln -sf ../xen-sys/$(XEN_OS) xen/sys
> > > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
> > > ln -s ../xen-foreign xen/foreign
> > > + ln -s $(XEN_ROOT)/xen/include/acpi acpi
> > > touch $@
> > >
> > > # Not xen/xsm as that clashes with link to
> > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > > index c4e4117..dac19ac 100644
> > > --- a/tools/libxl/Makefile
> > > +++ b/tools/libxl/Makefile
> > > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c:
> > > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
> > >
> > > libxl_arm_acpi.o: libxl_arm_acpi.c
> > > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> > > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c
> > > else
> > > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
> > > endif
> >
> > Thanks Stefano,
> > It hadn't occurred to me to add the acpi symlink :-).
> >
> > I can confirm that this fix works for me.
> >
>
> Right. I will turn this into a Tested-by tag. Thanks for testing.
>
> > ( I think we just delete the libxl_arm_acpi.o build rule and rely on
> > implicit make? )
> >
>
> Yes, that can be done. Patch is welcome. :-)
>
I don't know why, but my arm64 chroot is broken at the moment (hangs
from time to time, got TCG fatal error). I might submit a patch to
change that if I manage to fix my arm64 chroot. Feel free to submit a
patch to delete the explicit rule.
In the mean time, I've applied this patch as-is so that it passes
push-gate sooner.
Wei.
> Wei.
>
> > Cheers,
> > --
> > Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set
2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu
@ 2016-10-24 12:48 ` Jan Beulich
0 siblings, 0 replies; 14+ messages in thread
From: Jan Beulich @ 2016-10-24 12:48 UTC (permalink / raw)
To: Wei Liu; +Cc: Xen-devel
>>> On 14.10.16 at 19:02, <wei.liu2@citrix.com> wrote:
> It's better to have a explicit error than a build failure returned by
> gcc.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-10-24 12:48 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
2016-10-17 10:47 ` Wei Liu
2016-10-17 14:57 ` Steve Capper
2016-10-17 16:55 ` Wei Liu
2016-10-17 23:36 ` Stefano Stabellini
2016-10-18 7:52 ` Steve Capper
2016-10-18 11:21 ` Wei Liu
2016-10-18 11:43 ` Wei Liu
2016-10-18 11:17 ` Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu
2016-10-24 12:48 ` Jan Beulich
2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu
2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.