Bug#657853: Building perl with hardened build flags

[Niko Tyni]

On Sun, Feb 12, 2012 at 09:24:40PM +0100, Moritz Mühlenhoff wrote:
> On Sun, Feb 12, 2012 at 02:54:59PM +0200, Niko Tyni wrote:
> > > On Fri, Feb 10, 2012 at 11:29:09PM +0200, Niko Tyni wrote:

> > > > A. make debhelper pass all of CFLAGS, CPPFLAGS, and LDFLAGS down to
> > > >    ExtUtils::MakeMaker and ExtUtils::CBuilder via suitable command line
> > > >    invocations (it currently passes only CFLAGS, starting with compat
> > > >    level 9)
> 
> I would prefer this strategy.

I think it's my preferred alternative as well.

If we have consensus on that, the way forward as I see it:

- prepare a perl upload in unstable that is built with the hardened flags
  but doesn't export them through Config.pm
- preferably fix #660195 (recursive Makefile.PL arguments) while at it
- find the optimal invocations of Makefile.PL and Build.PL
  that honour all of CFLAGS, CPPFLAGS, and LDFLAGS
- either 
  + change the handful of release goal packages to use those invocations
    instead of the debhelper v9 defaults, and make debhelper v10 to use
    them by default after wheezy
  or
  + test the 30 or so affected packages and change debhelper v9
    for wheezy

For reference, the invocations I came up earlier were

 perl Makefile.PL OPTIMIZE="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
                  LD="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"

 perl Build.PL --config optimize="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
               --config ld="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"

but I didn't dwell long on that and there might be better ways to do
this. In particular, I think EU::CBuilder already honours some of the
flags so they might end up being used twice in the Build.PL version?

I don't have much time to work on this myself, help welcome.
-- 
Niko Tyni   ntyni at debian.org