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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Thu, 2015-02-05 at 11:18 +0000, Jan Beulich wrote:
> >>> On 05.02.15 at 12:08, <Ian.Jackson@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.