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 nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
