Re: Bug#657853: Building perl with hardened build flags
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
+ 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
+ test the 30 or so affected packages and change debhelper v9
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 email@example.com