Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[George Dunlap]

On Tue, Sep 1, 2015 at 4:10 PM, Ian Campbell  wrote:
> On Tue, 2015-09-01 at 15:54 +0100, George Dunlap wrote:
>>
>> I'm not sure exactly how to track down where it came from; it just
>> seems to appear out of nowhere in the config.log and config.status
>> (attached).
>
> How was configure invoked? Was this a command line build or inside the
> rpmbuild stuff?

Using rpmbuild.  Nothing in the .spec file says it's enabled; but
running "./configure [blah] ; make tools" directly seems to work just
fine, so it must be something w/ rpmbuild.

It would be a Nice To Have to allow debug builds to work with
_FORTIFY_SOURCE, but certainly not urgent.

I think for my purposes I'll just turn off debug builds for now.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[George Dunlap]

On Thu, Feb 5, 2015 at 4:52 PM, Jan Beulich  wrote:
 On 05.02.15 at 17:36,  wrote:
>> Some systems have python-config include -D_FORTIFY_SOURCE in the
>> CFLAGS.  But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
>> -O0 is enabled in debug builds (since 1166ecf781).  As a result, on
>> those systems, debug builds fail.
>>
>> Work around this problem as follows:
>>  * In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
>>  * If detected, set the new autoconf substitution and make variable
>>PY_NOOPT_CFLAGS to -O1.
>>  * In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
>>(which will override the -O0 with -O1 if required).
>
> Not having tried it out yet (hopefully some time tomorrow), two
> a remark and a question:
>
>> --- /dev/null
>> +++ b/m4/python_fortify_noopt.m4
>> @@ -0,0 +1,29 @@
>> +dnl Defines PY_NOOPT_CFLAGS to either '' or -O1
>> +dnl
>> +
>> +dnl This is necessary because on some systems setup.py includes
>> +dnl -D_FORTIFY_SOURCE but have a -D_FORTIFY_SOURCE which breaks
>> +dnl with -O0.  On those systems we arrange to use -O1 for debug
>> +dnl builds instead.
>> +
>> +AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
>> +AC_CACHE_CHECK([whether Python setup.py brokenly enables 
>> -D_FORTIFY_SOURCE],
>
> I guess the people having added that would not like to see this
> called "brokenly".
>
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -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 $(PY_NOOPT_CFLAGS)
>
> Why would you do this for all of the tools build rather than just the
> python components?

Because CentOS 7 somehow seems to have picked up _FORTIFY_SOURCE for libxc:

gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches   -m64 -mtune=generic -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   -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 .subdirs-install.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -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 .subdir-install-libxc.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -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 .build.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -D_GNU_SOURCE
-I../../xen/common/libelf -Werror -Wmissing-prototypes -I. -I./include
-I/build/centos/git/xen/BUILD/xen-4.6.0rc2x/tools/libxc/../../tools/include
-pthread -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 .xc_cpupool.o.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -D_GNU_SOURCE
-I../../xen/common/libelf -Werror -Wmissing-prototypes -I. -I./include
-I/build/centos/git/xen/BUILD/xen-4.6.0rc2x/tools/libxc/../../tools/include
-pthread -include
/build/centos/git/xen/BUILD/xen-4.6.0rc2x/tools/libxc/../../tools/config.h
 -c -o xc_cpupool.o xc_cpupool.c
In file included from /usr/include/unistd.h:25:0,
 from xc_private.h:19,
 from xc_altp2m.c:23:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Werror=cpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
In file included from /usr/include/unistd.h:25:0,
 from xg_private.h:19,
 from xc_core_x86.c:20:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Werror=cpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
In file included from /usr/include/unistd.h:25:0,
 from xc_private.h:19,
 from xc_cpupool.c:23:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Werror=cpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
In file included from /usr/include/unistd.h:25:0,
 from xg_private.h:19,
 from xc_core.c:63:

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Campbell]

On Tue, 2015-09-01 at 15:54 +0100, George Dunlap wrote:
> 
> I'm not sure exactly how to track down where it came from; it just
> seems to appear out of nowhere in the config.log and config.status
> (attached).

How was configure invoked? Was this a command line build or inside the
rpmbuild stuff?

Ian.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 17:56, ian.jack...@eu.citrix.com wrote:
 Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
  --- a/tools/Rules.mk
  +++ b/tools/Rules.mk
  @@ -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 $(PY_NOOPT_CFLAGS)
 
 Why would you do this for all of the tools build rather than just the
 python components?
 
 You're right.  This should be something like:
 
   CFLAGS += -O0 -g3
  +PY_CFLAGS += $(PY_NOOPT_CFLAGS)
 
 and including PY_CFLAGS in tools/python/Makefile etc.

Attached the patch I used for testing. While it works okay for me,
I guess the configure part will need further taking care of the
-Wp,-D... variant Don is seeing.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 06.02.15 at 09:19, jbeul...@suse.com wrote:
 Attached the patch I used for testing.

This time for real.

Jan

tools: work around collision of -O0 and -D_FORTIFY_SOURCE

Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS.  But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781).  As a result, on
those systems, debug builds fail.

Work around this problem as follows:
 * In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
 * If detected, set the new autoconf substitution and make variable
   PY_NOOPT_CFLAGS to -O1.
 * In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
   (which will override the -O0 with -O1 if required).

Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact.  A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Reported-by: Jan Beulich jbeul...@suse.com

Limit no-optimization override to Python interface code.

Signed-off-by: Jan Beulich jbeul...@suse.com

--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -13,6 +13,7 @@ BISON   := @BISON@
 FLEX:= @FLEX@
 PYTHON  := @PYTHON@
 PYTHON_PATH := @PYTHONPATH@
+PY_NOOPT_CFLAGS := @PY_NOOPT_CFLAGS@
 PERL:= @PERL@
 CURL_CONFIG := @CURL@
 XML2_CONFIG := @XML@
--- /dev/null
+++ b/m4/python_fortify_noopt.m4
@@ -0,0 +1,29 @@
+dnl Defines PY_NOOPT_CFLAGS to either '' or -O1
+dnl
+
+dnl This is necessary because on some systems setup.py includes
+dnl -D_FORTIFY_SOURCE but have a -D_FORTIFY_SOURCE which breaks
+dnl with -O0.  On those systems we arrange to use -O1 for debug
+dnl builds instead.
+
+AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
+AC_CACHE_CHECK([whether Python setup.py brokenly enables 
-D_FORTIFY_SOURCE],
+   [ax_cv_python_fortify],[
+ax_cv_python_fortify=no
+for arg in $($PYTHON-config --cflags); do
+case $arg in
+-D_FORTIFY_SOURCE=0) ax_cv_python_fortify=no ;;
+-D_FORTIFY_SOURCE=*) ax_cv_python_fortify=yes ;;
+*) ;;
+esac
+done
+])
+
+AS_IF([test x$ax_cv_python_fortify = xyes],[
+PY_NOOPT_CFLAGS=-O1
+], [
+PY_NOOPT_CFLAGS=''
+])
+
+AC_SUBST(PY_NOOPT_CFLAGS)
+])
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -57,6 +57,8 @@ SHLIB_libxenvchan  = -Wl,-rpath-link=$(X
 ifeq ($(debug),y)
 # Disable optimizations and enable debugging information for macros
 CFLAGS += -O0 -g3
+# But allow an override to -O0 in case Python enforces -D_FORTIFY_SOURCE=n.
+PY_CFLAGS += $(PY_NOOPT_CFLAGS)
 endif
 
 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
--- a/tools/configure
+++ b/tools/configure
@@ -652,6 +652,7 @@ PKG_CONFIG_LIBDIR
 PKG_CONFIG_PATH
 PKG_CONFIG
 CURSES_LIBS
+PY_NOOPT_CFLAGS
 EGREP
 GREP
 CPP
@@ -7043,6 +7044,38 @@ CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
 
 
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether Python setup.py 
brokenly enables -D_FORTIFY_SOURCE 5
+$as_echo_n checking whether Python setup.py brokenly enables 
-D_FORTIFY_SOURCE...  6; }
+if ${ax_cv_python_fortify+:} false; then :
+  $as_echo_n (cached)  6
+else
+
+ax_cv_python_fortify=no
+for arg in $($PYTHON-config --cflags); do
+case $arg in
+-D_FORTIFY_SOURCE=0) ax_cv_python_fortify=no ;;
+-D_FORTIFY_SOURCE=*) ax_cv_python_fortify=yes ;;
+*) ;;
+esac
+done
+
+fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $ax_cv_python_fortify 5
+$as_echo $ax_cv_python_fortify 6; }
+
+if test x$ax_cv_python_fortify = xyes; then :
+
+PY_NOOPT_CFLAGS=-O1
+
+else
+
+PY_NOOPT_CFLAGS=''
+
+fi
+
+
+
+
 fi
 
 if ! $rump; then
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -58,6 +58,7 @@ m4_include([../m4/checkpolicy.m4])
 m4_include([../m4/set_cflags_ldflags.m4])
 m4_include([../m4/python_version.m4])
 m4_include([../m4/python_devel.m4])
+m4_include([../m4/python_fortify_noopt.m4])
 m4_include([../m4/ocaml.m4])
 m4_include([../m4/uuid.m4])
 m4_include([../m4/pkg.m4])
@@ -295,6 +296,7 @@ AX_CHECK_PYTHON_VERSION([2], [3])
 
 AS_IF([test $cross_compiling != yes], [
 AX_CHECK_PYTHON_DEVEL()
+AX_CHECK_PYTHON_FORTIFY_NOOPT()
 ])
 
 if ! $rump; then
--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,15 +2,17 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_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) 

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE [and 1 more messages]

[Ian Jackson]

Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
-D_FORTIFY_SOURCE):
 Attached the patch I used for testing. While it works okay for me,
 I guess the configure part will need further taking care of the
 -Wp,-D... variant Don is seeing.

Thanks.  I'm going to pretend my first one was v2, you called your
version v3 and will send out a v4 in just a moment.

Don, can you please test it ?

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE [and 1 more messages]

[Don Slutz]

On 02/06/15 06:04, Ian Jackson wrote:
 Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
 -D_FORTIFY_SOURCE):
 Attached the patch I used for testing. While it works okay for me,
 I guess the configure part will need further taking care of the
 -Wp,-D... variant Don is seeing.
 
 Thanks.  I'm going to pretend my first one was v2, you called your
 version v3 and will send out a v4 in just a moment.
 
 Don, can you please test it ?
 

Will test it soon.
   -Don Slutz

 Thanks,
 Ian.
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Don Slutz]

On 02/05/15 05:17, Jan Beulich wrote:
 On 05.02.15 at 00:33, dsl...@verizon.com wrote:
 On 02/04/15 12:01, Jan Beulich wrote:
 The former gets enforced by our debug builds, the latter appears to be
 not uncommon for certain distros' Python packages. Newer glibc warns on
 uses of _FORTIFY_SOURCE without optimization being enabled, which with
 -Werror causes the build to fail.

 Determine Python's intended flags to be passed to the C compiler via
 python-config --cflags, and replace -O0 by -O1 when a non-zero value
 gets set for _FORTIFY_SOURCE.

 Signed-off-by: Jan Beulich jbeul...@suse.com

 Well, this does not fix debug=y builds for me:
 [...]
 gcc -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
 
 Where is this -Wp,-D_FORTIFY_SOURCE=2 coming from? Is
 python-config producing this? The patch provided certainly doesn't
 deal with that case.

Here is what I get for python-config:


dcs-xen-54:~/xen-masterpython-config --cflags
-I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv



 
 Using this change:

 dcs-xen-54:~/xen-mastergit show | cat
 commit 3cda306a162e55d73c25efc14840e7afeec8d3d3
 Author: Don Slutz dsl...@verizon.com
 Date:   Wed Feb 4 17:57:00 2015 -0500

 tools/Rules.mk: Drop -O0 for debug=y

 This is a partial revert of

 commit 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6
 Author: Euan Harris euan.har...@citrix.com
 Date:   Mon Dec 1 14:21:05 2014 +

 tools/Rules.mk: Don't optimize debug builds; add macro debugging
 information

 Signed-off-by: Don Slutz dsl...@verizon.com

 diff --git a/tools/Rules.mk b/tools/Rules.mk
 index 74cf37e..8bf603d 100644
 --- a/tools/Rules.mk
 +++ b/tools/Rules.mk
 @@ -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 += -g3
  endif

  LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)


 I can now build with debug=y on Fedora 17.
 
 If you went through the earlier discussion, you'd have seen that
 this was already rejected as a possible fix.

Sorry I did not see this.

   -Don Slutz

 
 Jan
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Euan Harris]

On Thu, Feb 05, 2015 at 03:26:00PM +, Ian Jackson wrote:
 Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
 -D_FORTIFY_SOURCE):
  For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
  incoming CFLAGS.
 
 Sorry, I meant PY_XCFLAGS='' or -O1 (as appropriate).
 
  And then I'm not really intending to fiddle with
  the configure scripts (albeit, having done the patch in the presented
  form, I expected you to want it done that way) - this and alike is
  what I specifically want to stay out of if at all possible. Since in any
  event commit 1166ecf781 introduced a regression for multiple
  people, perhaps if that is not supposed to be reverted Euan should
  look into addressing that regression?
 
 Since I'm being difficult, how about if I prepare patch to configure.
 Would you be able to test it ?

If it's not too much trouble, I'd be very grateful if you could do this.
My autotools knowledge is rusty, and I don't know when I'll have the 
opportunity to set up a machine which reproduces the problem (clearly
mine doesn't, otherwise I would have run into this problem before!)

Thanks,
Euan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Jackson]

Jan Beulich writes ([PATCH] tools: work around collision of -O0 and 
-D_FORTIFY_SOURCE):
 The former gets enforced by our debug builds, the latter appears to be
 not uncommon for certain distros' Python packages. Newer glibc warns on
 uses of _FORTIFY_SOURCE without optimization being enabled, which with
 -Werror causes the build to fail.
...
 --- a/tools/pygrub/Makefile
 +++ b/tools/pygrub/Makefile
 @@ -2,15 +2,24 @@
  XEN_ROOT = $(CURDIR)/../..
  include $(XEN_ROOT)/tools/Rules.mk
  
 +py_cflags := $(shell $(PYTHON)-config --cflags)
 +PY_CFLAGS = $(if $(strip $(py_cflags)),,\
 + $(error '$(PYTHON)-config --cflags' produced no output))\
 +$(if $(filter -D_FORTIFY_SOURCE=%,\
 +  $(filter-out -D_FORTIFY_SOURCE=0,\
 +   $(py_cflags))),\
 + $(patsubst -O0,-O1,$(CFLAGS)),\
 + $(CFLAGS)) $(APPEND_LDFLAGS)

There are lots of copies of this.  And it would IMO be better to do at
least the probing in configure, resulting in something like this in
configure:

 [ determine PY_XCFLAGS to be either '' or '-O0' ]
 AC_SUBST(PY_XCFLAGS)

and

 PY_CFLAGS=@PY_CFLAGS@

CC=$(CC) CFLAGS=$(CFLAGS) $(PY_XCFLAGS) $(PYTHON) setup.py build

(I assume that CFLAGS does override what comes out of setup.py.)

thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 16:26, ian.jack...@eu.citrix.com wrote:
 Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
 And then I'm not really intending to fiddle with
 the configure scripts (albeit, having done the patch in the presented
 form, I expected you to want it done that way) - this and alike is
 what I specifically want to stay out of if at all possible. Since in any
 event commit 1166ecf781 introduced a regression for multiple
 people, perhaps if that is not supposed to be reverted Euan should
 look into addressing that regression?
 
 Since I'm being difficult, how about if I prepare patch to configure.
 Would you be able to test it ?

Sure. Thanks!

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Jackson]

Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
-D_FORTIFY_SOURCE):
 For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
 incoming CFLAGS.

Sorry, I meant PY_XCFLAGS='' or -O1 (as appropriate).

 And then I'm not really intending to fiddle with
 the configure scripts (albeit, having done the patch in the presented
 form, I expected you to want it done that way) - this and alike is
 what I specifically want to stay out of if at all possible. Since in any
 event commit 1166ecf781 introduced a regression for multiple
 people, perhaps if that is not supposed to be reverted Euan should
 look into addressing that regression?

Since I'm being difficult, how about if I prepare patch to configure.
Would you be able to test it ?

None of my machines have the broken python setup.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Jackson]

Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS.  But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781).  As a result, on
those systems, debug builds fail.

Work around this problem as follows:
 * In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
 * If detected, set the new autoconf substitution and make variable
   PY_NOOPT_CFLAGS to -O1.
 * In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
   (which will override the -O0 with -O1 if required).

Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact.  A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Reported-by: Jan Beulich jbeul...@suse.com
CC: Jan Beulich jbeul...@suse.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Euan Harris euan.har...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: Don Slutz dsl...@verizon.com
---
 config/Tools.mk.in |1 +
 m4/python_fortify_noopt.m4 |   29 +
 tools/Rules.mk |2 +-
 tools/configure|   37 +
 tools/configure.ac |2 ++
 5 files changed, 70 insertions(+), 1 deletion(-)
 create mode 100644 m4/python_fortify_noopt.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 30267fa..e7da99d 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -13,6 +13,7 @@ BISON   := @BISON@
 FLEX:= @FLEX@
 PYTHON  := @PYTHON@
 PYTHON_PATH := @PYTHONPATH@
+PY_NOOPT_CFLAGS := @PY_NOOPT_CFLAGS@
 PERL:= @PERL@
 CURL_CONFIG := @CURL@
 XML2_CONFIG := @XML@
diff --git a/m4/python_fortify_noopt.m4 b/m4/python_fortify_noopt.m4
new file mode 100644
index 000..c399fa8
--- /dev/null
+++ b/m4/python_fortify_noopt.m4
@@ -0,0 +1,29 @@
+dnl Defines PY_NOOPT_CFLAGS to either '' or -O1
+dnl
+
+dnl This is necessary because on some systems setup.py includes
+dnl -D_FORTIFY_SOURCE but have a -D_FORTIFY_SOURCE which breaks
+dnl with -O0.  On those systems we arrange to use -O1 for debug
+dnl builds instead.
+
+AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
+AC_CACHE_CHECK([whether Python setup.py brokenly enables 
-D_FORTIFY_SOURCE],
+   [ax_cv_python_fortify],[
+ax_cv_python_fortify=no
+for arg in $($PYTHON-config --cflags); do
+case $arg in
+-D_FORTIFY_SOURCE=0) ax_cv_python_fortify=no ;;
+-D_FORTIFY_SOURCE=*) ax_cv_python_fortify=yes ;;
+*) ;;
+esac
+done
+])
+
+AS_IF([test x$ax_cv_python_fortify = xyes],[
+PY_NOOPT_CFLAGS=-O1
+], [
+PY_NOOPT_CFLAGS=''
+])
+
+AC_SUBST(PY_NOOPT_CFLAGS)
+])
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 74cf37e..c96efa2 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -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 $(PY_NOOPT_CFLAGS)
 endif
 
 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
diff --git a/tools/configure b/tools/configure
index ab04e8c..5fbe736 100755
--- a/tools/configure
+++ b/tools/configure
@@ -652,6 +652,7 @@ PKG_CONFIG_LIBDIR
 PKG_CONFIG_PATH
 PKG_CONFIG
 CURSES_LIBS
+PY_NOOPT_CFLAGS
 EGREP
 GREP
 CPP
@@ -3453,6 +3454,10 @@ esac
 
 
 
+
+
+
+
 # pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -7043,6 +7048,38 @@ CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
 
 
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether Python setup.py 
brokenly enables -D_FORTIFY_SOURCE 5
+$as_echo_n checking whether Python setup.py brokenly enables 
-D_FORTIFY_SOURCE...  6; }
+if ${ax_cv_python_fortify+:} false; then :
+  $as_echo_n (cached)  6
+else
+
+ax_cv_python_fortify=no
+for arg in $($PYTHON-config --cflags); do
+case $arg in
+-D_FORTIFY_SOURCE=0) ax_cv_python_fortify=no ;;
+-D_FORTIFY_SOURCE=*) ax_cv_python_fortify=yes ;;
+*) ;;
+esac
+done
+
+fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $ax_cv_python_fortify 5
+$as_echo $ax_cv_python_fortify 6; }
+
+if test x$ax_cv_python_fortify = xyes; then :
+
+PY_NOOPT_CFLAGS=-O1
+
+else
+
+PY_NOOPT_CFLAGS=''
+
+fi
+
+
+
+
 fi
 
 if ! $rump; then
diff --git a/tools/configure.ac b/tools/configure.ac
index d9cbf1f..03dadd7 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -58,6 +58,7 @@ m4_include([../m4/checkpolicy.m4])
 m4_include([../m4/set_cflags_ldflags.m4])
 

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 17:36, ian.jack...@eu.citrix.com wrote:
 Some systems have python-config include -D_FORTIFY_SOURCE in the
 CFLAGS.  But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
 -O0 is enabled in debug builds (since 1166ecf781).  As a result, on
 those systems, debug builds fail.
 
 Work around this problem as follows:
  * In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
  * If detected, set the new autoconf substitution and make variable
PY_NOOPT_CFLAGS to -O1.
  * In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
(which will override the -O0 with -O1 if required).

Not having tried it out yet (hopefully some time tomorrow), two
a remark and a question:

 --- /dev/null
 +++ b/m4/python_fortify_noopt.m4
 @@ -0,0 +1,29 @@
 +dnl Defines PY_NOOPT_CFLAGS to either '' or -O1
 +dnl
 +
 +dnl This is necessary because on some systems setup.py includes
 +dnl -D_FORTIFY_SOURCE but have a -D_FORTIFY_SOURCE which breaks
 +dnl with -O0.  On those systems we arrange to use -O1 for debug
 +dnl builds instead.
 +
 +AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
 +AC_CACHE_CHECK([whether Python setup.py brokenly enables 
 -D_FORTIFY_SOURCE],

I guess the people having added that would not like to see this
called brokenly.

 --- a/tools/Rules.mk
 +++ b/tools/Rules.mk
 @@ -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 $(PY_NOOPT_CFLAGS)

Why would you do this for all of the tools build rather than just the
python components?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Jackson]

Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
-D_FORTIFY_SOURCE):
 On 05.02.15 at 17:36, ian.jack...@eu.citrix.com wrote:
  +AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
  +AC_CACHE_CHECK([whether Python setup.py brokenly enables 
  -D_FORTIFY_SOURCE],
 
 I guess the people having added that would not like to see this
 called brokenly.

I think it is correct, and that it is fair to make such a criticism in
a configure script.  If this is too rude I guess we could say
`unfortunately'.

  --- a/tools/Rules.mk
  +++ b/tools/Rules.mk
  @@ -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 $(PY_NOOPT_CFLAGS)
 
 Why would you do this for all of the tools build rather than just the
 python components?

You're right.  This should be something like:

  CFLAGS += -O0 -g3
 +PY_CFLAGS += $(PY_NOOPT_CFLAGS)

and including PY_CFLAGS in tools/python/Makefile etc.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 17:56, ian.jack...@eu.citrix.com wrote:
  --- a/tools/Rules.mk
  +++ b/tools/Rules.mk
  @@ -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 $(PY_NOOPT_CFLAGS)
 
 Why would you do this for all of the tools build rather than just the
 python components?
 
 You're right.  This should be something like:
 
   CFLAGS += -O0 -g3
  +PY_CFLAGS += $(PY_NOOPT_CFLAGS)

I'll adjust this before testing. Thanks for the quick turnaround, btw!

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 00:33, dsl...@verizon.com wrote:
 On 02/04/15 12:01, Jan Beulich wrote:
 The former gets enforced by our debug builds, the latter appears to be
 not uncommon for certain distros' Python packages. Newer glibc warns on
 uses of _FORTIFY_SOURCE without optimization being enabled, which with
 -Werror causes the build to fail.
 
 Determine Python's intended flags to be passed to the C compiler via
 python-config --cflags, and replace -O0 by -O1 when a non-zero value
 gets set for _FORTIFY_SOURCE.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 
 Well, this does not fix debug=y builds for me:
 [...]
 gcc -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions

Where is this -Wp,-D_FORTIFY_SOURCE=2 coming from? Is
python-config producing this? The patch provided certainly doesn't
deal with that case.

 Using this change:
 
 dcs-xen-54:~/xen-mastergit show | cat
 commit 3cda306a162e55d73c25efc14840e7afeec8d3d3
 Author: Don Slutz dsl...@verizon.com
 Date:   Wed Feb 4 17:57:00 2015 -0500
 
 tools/Rules.mk: Drop -O0 for debug=y
 
 This is a partial revert of
 
 commit 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6
 Author: Euan Harris euan.har...@citrix.com
 Date:   Mon Dec 1 14:21:05 2014 +
 
 tools/Rules.mk: Don't optimize debug builds; add macro debugging
 information
 
 Signed-off-by: Don Slutz dsl...@verizon.com
 
 diff --git a/tools/Rules.mk b/tools/Rules.mk
 index 74cf37e..8bf603d 100644
 --- a/tools/Rules.mk
 +++ b/tools/Rules.mk
 @@ -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 += -g3
  endif
 
  LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
 
 
 I can now build with debug=y on Fedora 17.

If you went through the earlier discussion, you'd have seen that
this was already rejected as a possible fix.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Ian Campbell]

On Thu, 2015-02-05 at 11:18 +, Jan Beulich wrote:
  On 05.02.15 at 12:08, ian.jack...@eu.citrix.com wrote:
  Jan Beulich writes ([PATCH] tools: work around collision of -O0 and 
  -D_FORTIFY_SOURCE):
  The former gets enforced by our debug builds, the latter appears to be
  not uncommon for certain distros' Python packages. Newer glibc warns on
  uses of _FORTIFY_SOURCE without optimization being enabled, which with
  -Werror causes the build to fail.
  ...
  --- a/tools/pygrub/Makefile
  +++ b/tools/pygrub/Makefile
  @@ -2,15 +2,24 @@
   XEN_ROOT = $(CURDIR)/../..
   include $(XEN_ROOT)/tools/Rules.mk
   
  +py_cflags := $(shell $(PYTHON)-config --cflags)
  +PY_CFLAGS = $(if $(strip $(py_cflags)),,\
  + $(error '$(PYTHON)-config --cflags' produced no output))\
  +$(if $(filter -D_FORTIFY_SOURCE=%,\
  +  $(filter-out -D_FORTIFY_SOURCE=0,\
  +   $(py_cflags))),\
  + $(patsubst -O0,-O1,$(CFLAGS)),\
  + $(CFLAGS)) $(APPEND_LDFLAGS)
  
  There are lots of copies of this.  And it would IMO be better to do at
  least the probing in configure, resulting in something like this in
  configure:
  
   [ determine PY_XCFLAGS to be either '' or '-O0' ]
   AC_SUBST(PY_XCFLAGS)
  
  and
  
   PY_CFLAGS=@PY_CFLAGS@
  
  CC=$(CC) CFLAGS=$(CFLAGS) $(PY_XCFLAGS) $(PYTHON) setup.py build
  
  (I assume that CFLAGS does override what comes out of setup.py.)
 
 For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
 incoming CFLAGS. And then I'm not really intending to fiddle with
 the configure scripts (albeit, having done the patch in the presented
 form, I expected you to want it done that way) - this and alike is
 what I specifically want to stay out of if at all possible. Since in any
 event commit 1166ecf781 introduced a regression for multiple
 people, perhaps if that is not supposed to be reverted Euan should
 look into addressing that regression?

Euan -- do you think you might be able to whip up an autoconf-ification
along the lines of what is described above?

Ian.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

 On 05.02.15 at 12:08, ian.jack...@eu.citrix.com wrote:
 Jan Beulich writes ([PATCH] tools: work around collision of -O0 and 
 -D_FORTIFY_SOURCE):
 The former gets enforced by our debug builds, the latter appears to be
 not uncommon for certain distros' Python packages. Newer glibc warns on
 uses of _FORTIFY_SOURCE without optimization being enabled, which with
 -Werror causes the build to fail.
 ...
 --- a/tools/pygrub/Makefile
 +++ b/tools/pygrub/Makefile
 @@ -2,15 +2,24 @@
  XEN_ROOT = $(CURDIR)/../..
  include $(XEN_ROOT)/tools/Rules.mk
  
 +py_cflags := $(shell $(PYTHON)-config --cflags)
 +PY_CFLAGS = $(if $(strip $(py_cflags)),,\
 + $(error '$(PYTHON)-config --cflags' produced no output))\
 +$(if $(filter -D_FORTIFY_SOURCE=%,\
 +  $(filter-out -D_FORTIFY_SOURCE=0,\
 +   $(py_cflags))),\
 + $(patsubst -O0,-O1,$(CFLAGS)),\
 + $(CFLAGS)) $(APPEND_LDFLAGS)
 
 There are lots of copies of this.  And it would IMO be better to do at
 least the probing in configure, resulting in something like this in
 configure:
 
  [ determine PY_XCFLAGS to be either '' or '-O0' ]
  AC_SUBST(PY_XCFLAGS)
 
 and
 
  PY_CFLAGS=@PY_CFLAGS@
 
 CC=$(CC) CFLAGS=$(CFLAGS) $(PY_XCFLAGS) $(PYTHON) setup.py build
 
 (I assume that CFLAGS does override what comes out of setup.py.)

For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
incoming CFLAGS. And then I'm not really intending to fiddle with
the configure scripts (albeit, having done the patch in the presented
form, I expected you to want it done that way) - this and alike is
what I specifically want to stay out of if at all possible. Since in any
event commit 1166ecf781 introduced a regression for multiple
people, perhaps if that is not supposed to be reverted Euan should
look into addressing that regression?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

The former gets enforced by our debug builds, the latter appears to be
not uncommon for certain distros' Python packages. Newer glibc warns on
uses of _FORTIFY_SOURCE without optimization being enabled, which with
-Werror causes the build to fail.

Determine Python's intended flags to be passed to the C compiler via
python-config --cflags, and replace -O0 by -O1 when a non-zero value
gets set for _FORTIFY_SOURCE.

Signed-off-by: Jan Beulich jbeul...@suse.com

--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,15 +2,24 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(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 \
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -4,6 +4,15 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(CFLAGS)) $(LDFLAGS) $(APPEND_LDFLAGS)
+
 .PHONY: build
 build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
$(XEN_ROOT)/tools/libxl/idl.py
@@ -11,11 +20,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



tools: work around collision of -O0 and -D_FORTIFY_SOURCE

The former gets enforced by our debug builds, the latter appears to be
not uncommon for certain distros' Python packages. Newer glibc warns on
uses of _FORTIFY_SOURCE without optimization being enabled, which with
-Werror causes the build to fail.

Determine Python's intended flags to be passed to the C compiler via
python-config --cflags, and replace -O0 by -O1 when a non-zero value
gets set for _FORTIFY_SOURCE.

Signed-off-by: Jan Beulich jbeul...@suse.com

--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,15 +2,24 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(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 \
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -4,6 +4,15 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+ 

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Don Slutz]

On 02/04/15 12:01, Jan Beulich wrote:
 The former gets enforced by our debug builds, the latter appears to be
 not uncommon for certain distros' Python packages. Newer glibc warns on
 uses of _FORTIFY_SOURCE without optimization being enabled, which with
 -Werror causes the build to fail.
 
 Determine Python's intended flags to be passed to the C compiler via
 python-config --cflags, and replace -O0 by -O1 when a non-zero value
 gets set for _FORTIFY_SOURCE.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 

Well, this does not fix debug=y builds for me:

...
make -C python install
make[3]: Entering directory `/home/don/xen-master/tools/python'
CC=gcc CFLAGS=  -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
   python setup.py install \
--prefix=/usr --root=/home/don/xen-master/dist/install --force
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/xen
copying xen/__init__.py - build/lib.linux-x86_64-2.7/xen
creating build/lib.linux-x86_64-2.7/xen/lowlevel
copying xen/lowlevel/__init__.py - build/lib.linux-x86_64-2.7/xen/lowlevel
running build_ext
building 'xc' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/xen
creating build/temp.linux-x86_64-2.7/xen/lowlevel
creating build/temp.linux-x86_64-2.7/xen/lowlevel/xc
gcc -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -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:27:0,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/limits.h:169,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/syslimits.h:7,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/limits.h:34,
 from /usr/include/python2.7/Python.h:19,
 from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Werror=cpp]
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/don/xen-master/tools/python'
make[2]: *** [subdir-install-python] Error 2
make[2]: Leaving directory `/home/don/xen-master/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/don/xen-master/tools'
make: *** [install-tools] Error 2


Using this change:

dcs-xen-54:~/xen-mastergit show | cat
commit 3cda306a162e55d73c25efc14840e7afeec8d3d3
Author: Don Slutz dsl...@verizon.com
Date:   Wed Feb 4 17:57:00 2015 -0500

tools/Rules.mk: Drop -O0 for debug=y

This is a partial revert of

commit 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6
Author: Euan Harris euan.har...@citrix.com
Date:   Mon Dec 1 14:21:05 2014 +

tools/Rules.mk: Don't optimize debug builds; add macro debugging
information

Signed-off-by: Don Slutz dsl...@verizon.com

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 74cf37e..8bf603d 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -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 += -g3
 endif

 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)


I can now build with debug=y on Fedora 17.

   -Don Slutz




 --- a/tools/pygrub/Makefile
 +++ b/tools/pygrub/Makefile
 @@ -2,15 +2,24 @@
  XEN_ROOT = $(CURDIR)/../..
  include $(XEN_ROOT)/tools/Rules.mk
  
 +py_cflags := $(shell $(PYTHON)-config --cflags)
 +PY_CFLAGS = $(if $(strip $(py_cflags)),,\
 + $(error '$(PYTHON)-config --cflags' produced no output))\
 +$(if $(filter -D_FORTIFY_SOURCE=%,\
 +  $(filter-out -D_FORTIFY_SOURCE=0,\
 +   $(py_cflags))),\
 + $(patsubst -O0,-O1,$(CFLAGS)),\
 + $(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)