Re: [RFC PATCH] dpkg-buildflags: Switch to -fstack-protector-strong
Hi!
On Sun, 2014-06-29 at 01:15:37 -0400, Michael Gilbert wrote:
> On Thu, Jun 26, 2014 at 9:57 PM, Michael Gilbert wrote:
> > On Thu, Jun 26, 2014 at 7:57 AM, Romain Francoise wrote:
> >> I've already touched upon this elsewhere in this thread, but my personal
> >> feeling is that we don't want to go down that road. Detecting which
> >> compiler is used and parsing/comparing version numbers is bound to be
> >> fragile and require a lot of maintenance over time.
> >
> > Version comparison is something computers do incredibly well and
> > incredibly reliably all the time, so it isn't obvious why it would
> > suddenly fall apart here.
Version comparisons are not really good when testing for specific
features that might change depending on the implementation.
> Here is a slightly altered version of your patch that does this.
Thanks for this, although it is not realiable. The problem with “magic”
like this is that if it's not thorough, then its behaviour becomes hard
to explain and understand for the user, and it requires adding handling
of corner-cases over time, compared to simply “enabled when the default
compiler supports it, otherwise packaging or builder has to cope”. In
general whenever a packager or builder stop using the default toolchain,
they are on their own, that's why none of the existing options take into
account non-default compilers. But if we start doing so, here's some
issues with the patch:
* It gives wrong results when using clang which also has a -dumpversion,
but stuck at 4.2.1 (yes, some packages use clang as their compiler).
* It does not handle other compiler suites.
* It gives wrong results when using CC=gcc-4.8 CXX=g++ or other backends,
as each flag is dependent on the specific compiler backend being used.
* It requires not forgetting to pass the compiler variable to the
dpkg-buildflags invocation, or the result will be wrong.
> The following packages build correctly now with this applied:
>
> chromium
This is then one of the very few package really affected by this change.
TBH, I don't really see the point in the added complexity when changing
those very few packages is enough, when they are already setting a
different compiler explicitly anyway.
> contextfree
> spek
These two just use gcc/g++ 4.8 because they need features not
available before that. One C++11, the other C11 atomics. They should
just be switched to 4.9.
> These use an old style of passing buildflags that doesn't get CC/CXX
> exported early enough for dpkg-buildflags:
>
> flexc++
> gpg-remailer
> oxref
These three also use g++-4.8 due to C++11 features, should be switchable.
> Those can be fixed by manually adding CC/CXX in time, e.g.
>
> export CXXFLAGS=$(shell CXX=$(CXX) dpkg-buildflags --get CXXFLAGS)
>
> but that would also require an nmu.
If fixing those requires an upload they might as well just get properly
fixed to use gcc/g++ 4.9 instead.
Thanks,
Guillem
Reply to: