libxl/Makefile: Don't optimize debug builds; add macro debugging information
PATCH 1/1 libxl/Makefile: Don't optimize debug builds; add macro debugging information
libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.
--- tools/libxl/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
tools/libxl/Makefile +6 -0
@@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \ -Wno-declaration-after-statement -Wformat-nonliteral CFLAGS += -I. -fPIC +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + + ifeq ($(CONFIG_Linux),y) LIBUUID_LIBS += -luuid endif
Signature · 1 line
1.7.1
Quoted 5 lines · Euan Harris
libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.
I think if this argument applies (I see no reason to disagree) then it should apply to the whole of tools/* or at least to tools/lib* and not just to libxl. IOW this probably belongs at a higher level somewhere.
Quoted 3 lines
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.
Useful, I'd never heard of this. Do you know which version of gcc introduced it? (AKA do we need to make it part of configure.ac to check availability or not).
Not sure if you were proposing this change for 4.5 or not.
Quoted 23 lines
Signed-off-by Euan Harris <[email protected]>--- tools/libxl/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)tools/libxl/Makefile +6
-0@@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \ -Wno-declaration-after-statement -Wformat-nonliteral CFLAGS += -I. -fPIC +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + + ifeq ($(CONFIG_Linux),y) LIBUUID_LIBS += -luuid endif
Quoted 10 lines · Ian Campbell
Quoted 5 lines · Euan Harris
libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.I think if this argument applies (I see no reason to disagree) then it should apply to the whole of
tools/*or at least totools/lib*and not just to libxl. IOW this probably belongs at a higher level somewhere.
Ok, I'll submit a new patch putting it in tools/Rules.mk
Quoted 7 lines
Quoted 3 lines
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Useful, I'd never heard of this. Do you know which version of gcc introduced it? (AKA do we need to make it part of configure.ac to check availability or not).
It's documented in GCC 2.95.3 [1], which is as far back as the online manuals go.
[1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9
Quoted 1 line
Not sure if you were proposing this change for 4.5 or not.
It would be nice to have, but I was assuming that 4.5 was more or less closed by now.
Thanks,
Euan
Quoted 8 lines · Euan Harris
Quoted 7 lines · Ian Campbell
Quoted 5 lines · Euan Harris
libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.
Quoted 5 lines
Quoted 3 lines
I think if this argument applies (I see no reason to disagree) then it should apply to the whole of
tools/*or at least totools/lib*and not just to libxl. IOW this probably belongs at a higher level somewhere.Ok, I'll submit a new patch putting it in
tools/Rules.mk
Thanks.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.
Quoted 8 lines
Quoted 3 lines
Useful, I'd never heard of this. Do you know which version of gcc introduced it? (AKA do we need to make it part of configure.ac to check availability or not).
It's documented in GCC 2.95.3 [1], which is as far back as the online manuals go.
[1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9
OK, I'm pretty sure that's (way....) before our cut-off. Thanks.
Quoted 4 lines
Quoted 1 line
Not sure if you were proposing this change for 4.5 or not.
It would be nice to have, but I was assuming that 4.5 was more or less closed by now.
Exceptions can be asked/argued for. I'd be a bit wary of something like this since the knock-on effects might be a bit subtle. Completely fine during a dev window though.
Ian.
PATCH v2 1/1 tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.
Changes since v1:
* moved flag override to tools/Rules.mk so it affects all tools
--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
tools/Rules.mk +5 -0
@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2) ifeq ($(LIBXL_BLKTAP),y)
Signature · 1 line
1.7.1
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 4 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a userspace library.
(For others, that comment reads: Less than -O1 produces bad code and large stack frames)
Quoted 20 lines
Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +0
-0
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 58
Quoted 5 lines
tools/Rules.mk +2
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros
^enable
... or else it looks like you are saying it should be turning of macro debug info too. This is something which can be done on commit.
Quoted 6 lines
tools/Rules.mk +3
-0+CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2) ifeq ($(LIBXL_BLKTAP),y)
Ian Campbell
AppliedRe: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 8 lines · Ian Campbell
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 58
Quoted 2 lines
tools/Rules.mk +2
-0+ifeq ($(debug),y) +# Disable optimizations and debugging information for macros^enable
... or else it looks like you are saying it should be turning of macro debug info too. This is something which can be done on commit.
Acked-by Ian Campbell <[email protected]>
Applied, inserting "enable" as described.
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
In reply to Euan HarrisQuoted 25 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +0
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 10 lines
tools/Rules.mk +5
-0SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2) ifeq ($(LIBXL_BLKTAP),y)
This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/lowlevel
/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
In file included from /usr/include/limits.h:25:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168,
from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7,
from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34,
from /usr/include/python2.7/Python.h:19,
from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
The following patch can fix this problem:
Quoted 1 line
From
d16961971e14f6e50f9a9905449929d5a7c60860Mon Sep 17 00:00:00 2001
From: Wen Congyang <[email protected]>
Date: Tue, 13 Jan 2015 12:05:30 +0800
Subject: [PATCH] Fix a building error
Commit 1166ecf7 disables optimization. But _FORTIFY_SOURCE requires compiling with optimization (-O). Disable _FORTIFY_SOURCE by appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.
--- tools/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/Rules.mk +1 -1
@@ -56,7 +56,7 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 +CFLAGS += -O0 -g3 -Wp,-U_FORTIFY_SOURCE endif LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Signature · 1 line
2.1.0
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 34 lines · Wen Congyang
Quoted 33 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +5
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Quoted 5 lines
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 2 lines
tools/Rules.mk +0
-0ifeq ($(LIBXL_BLKTAP),y)This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/lowlev
el/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
Quoted 7 lines
In file included from
/usr/include/limits.h:25:0,from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34, from /usr/include/python2.7/Python.h:19, from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning_FORTIFY_SOURCErequires compiling with optimization (-O) [-Werror=cpp]
Where is _FORTIFY_SOURCE coming from? I don't see it in our tree anywhere except stubdom/Makefile which is disabling it and the build worked for me. Perhaps it is coming from your build environment somewhere? How are you configuring and building Xen?
Maybe what we want to do is only disable optimisations if debug=y AND -D_FORTIFY_SOURCE is not set? Might involve some autoconf checks to determine the fortification level in the user provided CFLAGS, which might be a bit faffsome.
Ian.
Quoted 34 lines
# warning
_FORTIFY_SOURCErequires compiling with optimization (-O)^cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1The following patch can fix this problem:
From
d16961971e14f6e50f9a9905449929d5a7c60860Mon Sep 17 00:00:00 2001
From: Wen Congyang <[email protected]>
Date: Tue, 13 Jan 2015 12:05:30 +0800
Subject: [PATCH] Fix a building errorCommit
1166ecf7disables optimization. But_FORTIFY_SOURCErequires compiling with optimization (-O). Disable_FORTIFY_SOURCEby appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.Signed-off-by Wen Congyang <[email protected]>--- tools/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tools/Rules.mk +1
-1@@ -56,7 +56,7 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 +CFLAGS += -O0 -g3 -Wp,-U_FORTIFY_SOURCE endif LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 35 lines · Ian Campbell
Quoted 34 lines · Wen Congyang
Quoted 33 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +5
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Quoted 5 lines
Quoted 5 lines
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 2 lines
tools/Rules.mk +0
-0ifeq ($(LIBXL_BLKTAP),y)This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/lowle
vel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
Quoted 8 lines
Quoted 7 lines
In file included from
/usr/include/limits.h:25:0,from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34, from /usr/include/python2.7/Python.h:19, from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning_FORTIFY_SOURCErequires compiling with optimization (-O) [-Werror=cpp]
Quoted 4 lines
Where is
_FORTIFY_SOURCEcoming from? I don't see it in our tree anywhere except stubdom/Makefile which is disabling it and the build worked for me. Perhaps it is coming from your build environment somewhere? How are you configuring and building Xen?
I don't knwo where is _FORTIFY_SOURCE coming from.
I use fedora 21 to build xen. The command line is:
./autogen.sh
./configure --prefix=/usr --libdir=/usr/lib64 make -j8 tools
Thanks
Wen Congyang
Quoted 46 lines
Maybe what we want to do is only disable optimisations if debug=y AND -D_FORTIFY_SOURCE is not set? Might involve some autoconf checks to determine the fortification level in the user provided CFLAGS, which might be a bit faffsome.
Ian.
Quoted 26 lines
# warning
_FORTIFY_SOURCErequires compiling with optimization (-O)^cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1The following patch can fix this problem:
From
d16961971e14f6e50f9a9905449929d5a7c60860Mon Sep 17 00:00:00 2001
From: Wen Congyang <[email protected]>
Date: Tue, 13 Jan 2015 12:05:30 +0800
Subject: [PATCH] Fix a building errorCommit
1166ecf7disables optimization. But_FORTIFY_SOURCErequires compiling with optimization (-O). Disable_FORTIFY_SOURCEby appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.Signed-off-by Wen Congyang <[email protected]>--- tools/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tools/Rules.mk +0
-0tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 62
Quoted 8 lines
tools/Rules.mk +1
-1@@ -56,7 +56,7 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 +CFLAGS += -O0 -g3 -Wp,-U_FORTIFY_SOURCE endif LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2).
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
In reply to Ian CampbellQuoted 35 lines · Ian Campbell
Quoted 34 lines · Wen Congyang
Quoted 33 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +5
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Quoted 5 lines
Quoted 5 lines
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 2 lines
tools/Rules.mk +0
-0ifeq ($(LIBXL_BLKTAP),y)This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/lowle
vel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
Quoted 8 lines
Quoted 7 lines
In file included from
/usr/include/limits.h:25:0,from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34, from /usr/include/python2.7/Python.h:19, from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning_FORTIFY_SOURCErequires compiling with optimization (-O) [-Werror=cpp]
Quoted 4 lines
Where is
_FORTIFY_SOURCEcoming from? I don't see it in our tree anywhere except stubdom/Makefile which is disabling it and the build worked for me. Perhaps it is coming from your build environment somewhere? How are you configuring and building Xen?
_FORTIFY_SOURCE is just for python, and it comes from /usr/lib64/python2.7/config/Makefile:
# Compiler options
OPT= -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
BASECFLAGS= -fno-strict-aliasing
CFLAGS= $(BASECFLAGS) -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv $(OPT) $(EXTRA_CFLAGS)
Quoted 46 lines
Maybe what we want to do is only disable optimisations if debug=y AND -D_FORTIFY_SOURCE is not set? Might involve some autoconf checks to determine the fortification level in the user provided CFLAGS, which might be a bit faffsome.
Ian.
Quoted 26 lines
# warning
_FORTIFY_SOURCErequires compiling with optimization (-O)^cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1The following patch can fix this problem:
From
d16961971e14f6e50f9a9905449929d5a7c60860Mon Sep 17 00:00:00 2001
From: Wen Congyang <[email protected]>
Date: Tue, 13 Jan 2015 12:05:30 +0800
Subject: [PATCH] Fix a building errorCommit
1166ecf7disables optimization. But_FORTIFY_SOURCErequires compiling with optimization (-O). Disable_FORTIFY_SOURCEby appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.Signed-off-by Wen Congyang <[email protected]>--- tools/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tools/Rules.mk +0
-0tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 62
Quoted 8 lines
tools/Rules.mk +1
-1@@ -56,7 +56,7 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 +CFLAGS += -O0 -g3 -Wp,-U_FORTIFY_SOURCE endif LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2).
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 36 lines · Wen Congyang
Quoted 35 lines · Ian Campbell
Quoted 34 lines · Wen Congyang
Quoted 33 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +5
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 2 lines
tools/Rules.mk +0
-0ifeq ($(LIBXL_BLKTAP),y)This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/low
level/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
Quoted 13 lines
Quoted 8 lines
Quoted 7 lines
In file included from
/usr/include/limits.h:25:0,from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34, from /usr/include/python2.7/Python.h:19, from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning_FORTIFY_SOURCErequires compiling with optimization (-O) [-Werror=cpp]Quoted 4 lines
Where is
_FORTIFY_SOURCEcoming from? I don't see it in our tree anywhere except stubdom/Makefile which is disabling it and the build worked for me. Perhaps it is coming from your build environment somewhere? How are you configuring and building Xen?
Quoted 7 lines
_FORTIFY_SOURCEis just for python, and it comes from/usr/lib64/python2.7/config/Makefile:# Compiler options
OPT= -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
BASECFLAGS= -fno-strict-aliasing
CFLAGS= $(BASECFLAGS) -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv $(OPT) $(EXTRA_CFLAGS)
That's a bit antisocial of it...
I can't reproduce this on Debian with Python 2.7. _FORTIFY_SOURCE=2 is not passed when building the Python bits (it is passed when linking, oddly). Debian's /usr/lib/python2.7/config-x86_64-linux-gnu/Makefile looks rather different to what you quote above though, it avoids bare CFLAGS for one thing (reserving them for the user).
I have a suspicion that this might be a bug in the Fedora Python packaging, in that they have leaked inappropriate build-time flags from the actual Python build into the set of flags to be used to build 3rd party Python modules.
Please can you check this with the Fedora folks? If they respond that this is deliberate etc then please let us know and we'll see what we can do in Xen to work around it.
Ian.
Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Quoted 37 lines · Ian Campbell
Quoted 36 lines · Wen Congyang
Quoted 35 lines · Ian Campbell
Quoted 34 lines · Wen Congyang
Quoted 33 lines · Euan Harris
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.Signed-off-by Euan Harris <[email protected]>Changes since v1:
* moved flag override totools/Rules.mkso it affects all tools--- tools/Rules.mk | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)tools/Rules.mk +5
-0@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) +ifeq ($(debug),y) +# Disable optimizations and debugging information for macros +CFLAGS += -O0 -g3 +endif + LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
tools/Rules.mk CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) · line 64
Quoted 2 lines
tools/Rules.mk +0
-0ifeq ($(LIBXL_BLKTAP),y)This patch causes a building error:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -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_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/low
level/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
Quoted 29 lines
Quoted 13 lines
Quoted 8 lines
Quoted 7 lines
In file included from
/usr/include/limits.h:25:0,from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34, from /usr/include/python2.7/Python.h:19, from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:328:4: error: #warning_FORTIFY_SOURCErequires compiling with optimization (-O) [-Werror=cpp]Quoted 4 lines
Where is
_FORTIFY_SOURCEcoming from? I don't see it in our tree anywhere except stubdom/Makefile which is disabling it and the build worked for me. Perhaps it is coming from your build environment somewhere? How are you configuring and building Xen?Quoted 7 lines
_FORTIFY_SOURCEis just for python, and it comes from/usr/lib64/python2.7/config/Makefile:# Compiler options
OPT= -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
BASECFLAGS= -fno-strict-aliasing
CFLAGS= $(BASECFLAGS) -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv $(OPT) $(EXTRA_CFLAGS)That's a bit antisocial of it...
I can't reproduce this on Debian with Python 2.7. _FORTIFY_SOURCE=2 is not passed when building the Python bits (it is passed when linking, oddly). Debian's
/usr/lib/python2.7/config-x86_64-linux-gnu/Makefilelooks rather different to what you quote above though, it avoids bare CFLAGS for one thing (reserving them for the user).
Quoted 8 lines
I have a suspicion that this might be a bug in the Fedora Python packaging, in that they have leaked inappropriate build-time flags from the actual Python build into the set of flags to be used to build 3rd party Python modules.
Please can you check this with the Fedora folks? If they respond that this is deliberate etc then please let us know and we'll see what we can do in Xen to work around it.
Here is the reponse from Fedora folks:
-------- Forwarded Message --------
Subject: Re: [Xen-devel] [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Date: Wed, 14 Jan 2015 12:22:19 -0500
From: Bohuslav Kabrda <[email protected]>
To: Wen Congyang <[email protected]>
----- Original Message -----
Quoted 11 lines
Hi, bkabrda
When I build some python modules in xen, I find some building error.
The reason is that: we need to disable optimization by -O0, but the CFLAGS in python's
Makefilehave -Wp,-D_FORTIFY_SOURCE=2.My question is that: Is this flag essential?
Thanks
Wen Congyang
Hi,
all the flags come from default RPM build configuration that all Fedora packages are supposed to use. They are saved by Python's build process to config/Makefile. Running "setup.py build" then uses them for building extension modules. So to answer your question: yes, this is mandated by Fedora and will not go away. Now, there are two solutions to your situation I can see:
- either add "undef_macros" to setup.py definition of the extension module, as documented at [1]
- run "setup.py build" in environment where you set "CFLAGS=-U_FORTIFY_SOURCE"
Both will do the same - undefine the _FORTIFY_SOURCE macro in the gcc invocations.
Hope this helps,
Slavek.
[1] https://docs.python.org/2/distutils/setupscript.html#preprocessor-options
Quoted 5 lines
Ian.
.
PATCH 1/1 Fix building error
In reply to Euan HarrisCommit 1166ecf7 disables optimization. But python's build process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose the 3rd party python modules to use. The macro _FORTIFY_SOURCE requires compiling with optimization (-O). Disable _FORTIFY_SOURCE by appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.
--- tools/pygrub/Makefile | 5 +++++ tools/python/Makefile | 5 +++++ 2 files changed, 10 insertions(+)
tools/pygrub/Makefile +5 -0
@@ -2,6 +2,11 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk +ifeq ($(debug),y) +# Disable _FORTIFY_SOURCE +CFLAGS += -Wp,-U_FORTIFY_SOURCE +endif + .PHONY: all all: build .PHONY: build
tools/python/Makefile +5 -0
@@ -4,6 +4,11 @@ include $(XEN_ROOT)/tools/Rules.mk .PHONY: all all: build +ifeq ($(debug),y) +# Disable _FORTIFY_SOURCE +CFLAGS += -Wp,-U_FORTIFY_SOURCE +endif + .PHONY: build build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/idl.py
Signature · 1 line
2.1.0
Re: [PATCH] Fix building error
Quoted 5 lines · Wen Congyang
Commit
1166ecf7disables optimization. But python's build process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose the 3rd party python modules to use. The macro_FORTIFY_SOURCErequires compiling with optimization (-O). Disable_FORTIFY_SOURCEby appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.
Why is that not done globally, in the place where -O is tweaked? The comment can be removed, it states the obvious.
Olaf
Re: [PATCH] Fix building error
Quoted 10 lines · Olaf Hering
Quoted 5 lines · Wen Congyang
Commit
1166ecf7disables optimization. But python's build process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose the 3rd party python modules to use. The macro_FORTIFY_SOURCErequires compiling with optimization (-O). Disable_FORTIFY_SOURCEby appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.Why is that not done globally, in the place where -O is tweaked? The comment can be removed, it states the obvious.
Xen doesn't use the macro _FORTIFY_SOURCE, so it only affects python modules now.
Thanks
Wen Congyang
Quoted 3 lines
Olaf
Re: [PATCH] Fix building error
Quoted 2 lines · Wen Congyang
Xen doesn't use the macro
_FORTIFY_SOURCE, so it only affects python modules now.
It does if it is passed via global CFLAGS, like the RPM_OPT_FLAGS from a rpm package build.
Olaf
Re: [PATCH] Fix building error
Quoted 7 lines · Olaf Hering
Quoted 2 lines · Wen Congyang
Xen doesn't use the macro
_FORTIFY_SOURCE, so it only affects python modules now.It does if it is passed via global CFLAGS, like the
RPM_OPT_FLAGSfrom a rpm package build.
Yes, I don't consider such case. I will send a new patch later.
Thanks
Wen Congyang
Quoted 3 lines
Olaf
PATCH v2 1/1 Fix building error
--- tools/Rules.mk | 2 ++ 1 file changed, 2 insertions(+)
tools/Rules.mk +2 -0
@@ -57,6 +57,8 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3 +# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCE endif LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
Signature · 1 line
2.1.0
Re: [PATCH v2] Fix building error
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCE
I'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible I think the right answer is for an affected developer to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.
To make this easier to do without editing tools/Rules.mk I would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.
Thanks,
Ian.
Re: [PATCH v2] Fix building error
Quoted 20 lines · Ian Jackson
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
Quoted 5 lines
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible
I think so, see <[email protected]>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc.
Quoted 2 lines
I think the right
answer is for an affected developer
Which will be all developers using Fedora AFAICT.
Quoted 8 lines
to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.To make this easier to do without editing
tools/Rules.mkI would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.
This seems reasonable enough to me.
The original patch in <[email protected]> (correctly IMHO) applied the workaround only to the Python parts of the build (tools/{python,pygrub}) whereas this v2 and your suggestion would affect all of tools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice).
Ian.
Re: [PATCH v2] Fix building error
Quoted 32 lines · Ian Campbell
Quoted 20 lines · Ian Jackson
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
Quoted 5 lines
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible
I think so, see <[email protected]>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc.
Quoted 13 lines
Quoted 2 lines
I think the right
answer is for an affected developerWhich will be all developers using Fedora AFAICT.
Quoted 8 lines
to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.To make this easier to do without editing
tools/Rules.mkI would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.
I don't understand your suggestion.
Quoted 9 lines
This seems reasonable enough to me.
The original patch in <[email protected]> (correctly IMHO) applied the workaround only to the Python parts of the build (
tools/{python,pygrub}) whereas this v2 and your suggestion would affect all oftools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice).
Building problems only affect developers, so I think we should fix this problem.
If the developers add extra flags to define the macro _FORTIFY_SOURCE, it also breaks building. We can disable debug for such case, or undefine the macro in Rules.mk. If the macro _FORTIFY_SOURCE is not defined, undefining it is harmless.
Thanks
Wen Congyang
Quoted 5 lines
Ian.
.
Re: [PATCH v2] Fix building error
Quoted 43 lines · Wen Congyang
Quoted 42 lines · Ian Campbell
Quoted 20 lines · Ian Jackson
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
Quoted 5 lines
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible
I think so, see <[email protected]>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc.
Quoted 2 lines
I think the right
answer is for an affected developerWhich will be all developers using Fedora AFAICT.
Quoted 5 lines
to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
To make this easier to do without editing
tools/Rules.mkI would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.I don't understand your suggestion.
He means for the build system to honour a new EXTRA_FLAGS_XEN_TOOLS_DEBUG (or similar) iff debug=y.
Quoted 9 lines
Quoted 8 lines
This seems reasonable enough to me.
The original patch in <[email protected]> (correctly IMHO) applied the workaround only to the Python parts of the build (
tools/{python,pygrub}) whereas this v2 and your suggestion would affect all oftools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice).
Quoted 4 lines
Building problems only affect developers, so I think we should fix this problem.
If the developers add extra flags to define the macro
_FORTIFY_SOURCE, it also breaks building.
So can adding all manner of random macros to the build. If a developer adds such flags then they should be prepared to deal with the consequences, including dealing with any breakage which results.
The only reason we aren't taking this hard line with the situation you find yourself in is that a major distro has seen fit to define these extra macros into the default Python build system on that distro, hence we are trying to find a reasonable compromise for users/developers of that distro without making things worse for users/developers of other distros which don't do this.
Quoted 2 lines
We can disable debug for such case, or undefine the macro
in Rules.mk. If the macro_FORTIFY_SOURCEis not defined, undefining it is harmless.
On the other hand a user who has a fixed version of fortify which is compatible with -O0 then cannot enable it if we do this.
Ian.
Re: [PATCH v2] Fix building error
Quoted 62 lines · Ian Campbell
Quoted 43 lines · Wen Congyang
Quoted 42 lines · Ian Campbell
Quoted 20 lines · Ian Jackson
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
Quoted 5 lines
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible
I think so, see <[email protected]>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc.
Quoted 2 lines
I think the right
answer is for an affected developerWhich will be all developers using Fedora AFAICT.
Quoted 5 lines
to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
To make this easier to do without editing
tools/Rules.mkI would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.I don't understand your suggestion.
He means for the build system to honour a new
EXTRA_FLAGS_XEN_TOOLS_DEBUG(or similar) iff debug=y.Quoted 9 lines
Quoted 8 lines
This seems reasonable enough to me.
The original patch in <[email protected]> (correctly IMHO) applied the workaround only to the Python parts of the build (
tools/{python,pygrub}) whereas this v2 and your suggestion would affect all oftools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice).
Quoted 8 lines
Quoted 4 lines
Building problems only affect developers, so I think we should fix this problem.
If the developers add extra flags to define the macro
_FORTIFY_SOURCE, it also breaks building.So can adding all manner of random macros to the build. If a developer adds such flags then they should be prepared to deal with the consequences, including dealing with any breakage which results.
Agree with it.
Quoted 8 lines
The only reason we aren't taking this hard line with the situation you find yourself in is that a major distro has seen fit to define these extra macros into the default Python build system on that distro, hence we are trying to find a reasonable compromise for users/developers of that distro without making things worse for users/developers of other distros which don't do this.
Quoted 5 lines
Quoted 2 lines
We can disable debug for such case, or undefine the macro
in Rules.mk. If the macro_FORTIFY_SOURCEis not defined, undefining it is harmless.On the other hand a user who has a fixed version of fortify which is compatible with -O0 then cannot enable it if we do this.
Yes. We can detect it in the configure. And only undefine it when fortify cannot work with -O0
Thanks
Wen Congyang
Quoted 5 lines
Ian.
.
Re: [PATCH v2] Fix building error
In reply to Ian CampbellQuoted 6 lines · Ian Campbell
The original patch in <[email protected]> (correctly IMHO) applied the workaround only to the Python parts of the build (
tools/{python,pygrub}) whereas this v2 and your suggestion would affect all oftools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice).
After looking again at this the original patch seems to be the correct workaround.
Olaf
Re: [PATCH v2] Fix building error
In reply to Ian CampbellHi,
Quoted 25 lines · Ian Campbell
Quoted 24 lines · Ian Jackson
Wen Congyang writes ("[PATCH v2] Fix building error"):
tools/Rules.mk SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) · line 61
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3tools/Rules.mk +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Quoted 6 lines
Quoted 1 line
Assuming that the underlying bug is intractible
I think so, see <[email protected]>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc.
FWIW, I get the same error when building tools on OpenSuse.
I would find annoying to manually override the CFLAGS everytime I have to build Xen.
Regards,
Signature · 1 line
Julien Grall
Re: [PATCH v2] Fix building error
In reply to Ian JacksonQuoted 31 lines
Quoted 1 line
Quoted 1 line · On 15.01.15 at 12:26, <[email protected]> wrote:
Wen Congyang writes ("[PATCH v2] Fix building error"):
Review
Quoted 5 lines
ifeq ($(debug),y)
# Disable optimizations and enable debugging information for macros CFLAGS += -O0 -g3(quoted diff) +2
-0+# _FORTIFY_SOURCE requires compiling with optimization +CFLAGS += -Wp,-U_FORTIFY_SOURCEI'm not entirely convinced about this. I have two kinds of concern:
One is practical, which is that ATM AIUI a debug build, while not intended for production use, is not any less secure. (Leaving aside the ability of guests to perform a DoS with copious debugging output.)
The other is that we seem to be entering into a battle of escalation between various Makefiles. Specifically, this seems to be a workaround for a bug in some other Makefiles we are using: the bug being that these other Makefiles can't cope with -O0. And unconditionally squashing the other Makefiles' options seems like a big hammer.
The fact that Fortify doesn't support -O0 is a property of Fortify which ought to be encoded in Fortify (or the places where it is enabled).
Assuming that the underlying bug is intractible I think the right answer is for an affected developer to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.
Quoted 3 lines
To make this easier to do without editing
tools/Rules.mkI would support a patch to Rules.mk which has it honour a variable containing a debug-specific set of CFLAGS.
Having run into this just now too, and seeing that the previous discussion didn't really lead anywhere, I wonder what should be done about this. I check as far back as I reasonably could, and glibc apparently never supported _FORTIFY_SOURCE without optimization. The change in behavior at some point simply was that rather than disabling this silently, they now warn about it (which of course is fatal for a build with -Werror). I also checked Python, and they also seem to have been enabling _FORTIFY_SOURCE forever. Consequently, with the previously suggested patches not having found acceptance, how about
tools/pygrub/Makefile +4 -2
@@ -2,15 +2,17 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk +PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS) + .PHONY: all all: build .PHONY: build build: - CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build .PHONY: install install: all - CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py install \ + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \ $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \ --install-scripts=$(LIBEXEC_BIN) --force set -e; if [ $(BINDIR) != $(LIBEXEC_BIN) -a \
tools/python/Makefile +4 -2
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk .PHONY: all all: build +PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(LDFLAGS) $(APPEND_LDFLAGS) + .PHONY: build build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/idl.py
@@ -11,11 +13,11 @@ build: genwrap.py $(XEN_ROOT)/tools/libx $(XEN_ROOT)/tools/libxl/libxl_types.idl \ xen/lowlevel/xl/_pyxl_types.h \ xen/lowlevel/xl/_pyxl_types.c - CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build .PHONY: install install: - CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py install \ + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \ $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force .PHONY: test
Jan
Re: [PATCH v2] Fix building error
Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
Quoted 6 lines · On 15.01.15 at 12:26, <[email protected]> wrote:
Quoted 5 lines
Assuming that the underlying bug is intractible I think the right answer is for an affected developer to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting.
...
Quoted 10 lines
Having run into this just now too, and seeing that the previous discussion didn't really lead anywhere, I wonder what should be done about this. I check as far back as I reasonably could, and glibc apparently never supported
_FORTIFY_SOURCEwithout optimization. The change in behavior at some point simply was that rather than disabling this silently, they now warn about it (which of course is fatal for a build with -Werror). I also checked Python, and they also seem to have been enabling_FORTIFY_SOURCEforever. Consequently, with the previously suggested patches not having found acceptance, how about
...
Quoted 1 line
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)
This is still bad. What if the user explicitly wants to build without optimisation ? That's not unusual. And it's only the combination of -O0 and FORTIFY that fails. (And it's only on broken platforms that FORTIFY appears by default.)
I guess I would tolerate a patch which spots the combination of _FORTIFY_SOURCE and -O0 and only in that case changes -O1 to -O0.
Ian.
Re: [PATCH v2] Fix building error
Quoted 19 lines
Quoted 1 line
Quoted 1 line · On 04.02.15 at 16:43, <[email protected]> wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
Quoted 6 lines · On 15.01.15 at 12:26, <[email protected]> wrote:
Quoted 5 lines
Assuming that the underlying bug is intractible I think the right answer is for an affected developer to do one of the following, as a
workaround: either, manually override Fortify when requesting a debug build (by settingEXTRA_CFLAGS_XEN_TOOLS), or manually override the -O0 setting....
Quoted 10 lines
Having run into this just now too, and seeing that the previous discussion didn't really lead anywhere, I wonder what should be done about this. I check as far back as I reasonably could, and glibc apparently never supported
_FORTIFY_SOURCEwithout optimization. The change in behavior at some point simply was that rather than disabling this silently, they now warn about it (which of course is fatal for a build with -Werror). I also checked Python, and they also seem to have been enabling_FORTIFY_SOURCEforever. Consequently, with the previously suggested patches not having found acceptance, how about
Quoted 7 lines
...
Quoted 1 line
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)
This is still bad. What if the user explicitly wants to build without optimisation ? That's not unusual. And it's only the combination of -O0 and FORTIFY that fails. (And it's only on broken platforms that FORTIFY appears by default.)
Broken platforms? (Of course I ask without having any idea where python-config takes that -D_FORTIFY_SOURCE=2 [together with everything else it sets] from.)
Also I think overriding -O<n> here is no worse that Python adding -DNDEBUG regardless of us doing a debug build. (Besides they actually do pass -O2 too, just that our additions override this.)
Quoted 2 lines
I guess I would tolerate a patch which spots the combination of
_FORTIFY_SOURCEand -O0 and only in that case changes -O1 to -O0.
But that would have to happen in (I guess) setup.py, unless we want to invoke "python-config --cflags" from the Makefile to find out. And I don't see myself touching any Python code...
Jan
Re: [PATCH v2] Fix building error
Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
Quoted 9 lines · On 04.02.15 at 16:43, <[email protected]> wrote:
Quoted 4 lines
This is still bad. What if the user explicitly wants to build without optimisation ? That's not unusual. And it's only the combination of -O0 and FORTIFY that fails. (And it's only on broken platforms that FORTIFY appears by default.)
Broken platforms? (Of course I ask without having any idea where python-config takes that -D_FORTIFY_SOURCE=2 [together with everything else it sets] from.)
IMO a platform where the standard Python build tools produce compiler options incompatible with -O0 is broken.
Quoted 2 lines
Also I think overriding -O<n> here is no worse that Python adding -DNDEBUG regardless of us doing a debug build.
What??? I'm just not going there.
Quoted 6 lines
Quoted 2 lines
I guess I would tolerate a patch which spots the combination of
_FORTIFY_SOURCEand -O0 and only in that case changes -O1 to -O0.But that would have to happen in (I guess)
setup.py, unless we want to invoke "python-config --cflags" from theMakefileto find out. And I don't see myself touching any Python code...
I don't mind some kind of configure check for this particular brokenness. python-config --cflags seems like it would be a fine way to detect it.
Ian.
Re: [PATCH v2] Fix building error
In reply to Jan BeulichQuoted 3 lines · Jan Beulich
I also checked Python, and they also seem to have been enabling
_FORTIFY_SOURCEforever. Consequently, with the previously suggested patches not having found acceptance, how about
I'm sure python just carries the CFLAGS used for its build, so that other python related code can use the very same CFLAGS. IMO that is valid. Since the whole distro is built with those CFLAGS via RPM_OPT_FLAGS it will end up also in python.
I wonder, is it just SUSE and Fedora that use _FORTIFY_SOURCE in global CFLAGS?
Olaf