[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] Fix building error



Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
> On 15.01.15 at 12:26, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> > 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.
...
> 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
...
> +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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.