Bug#769265: Patch for lib/Marpa/R2.pm

[Niko Tyni]

clone 769265 -1
retitle -1 cdbs: perl-build-vars.mk overrides $Config{ccflags}
reassign -1 cdbs 0.4.127
# maybe serious, not quite sure
severity -1 important
submitter -1 !
thanks

On Sat, Nov 22, 2014 at 04:39:19PM +0100, gregor herrmann wrote:

> I've tested your patch (minus the version bump) now in an i386
> chroot, and unfortunately the tests still fail:

I looked into this a bit, and the actual problem here seems to be that
the package build system compiles the XS code without $Config{ccflags},
causing a binary incompatibility (probably because -D_FILE_OFFSET_BITS=64
is missing) and leading into the segfault.

[Jeffrey: as a summary, I think this is a bug in the Debian packaging.
 It looks to me like Marpa::R2::Build_Me is doing the right thing but
 the packaging tells Module::Build to ignore that.]

The patch in 2.086000~dfsg-4 disabling 
 call_list(PL_scopestack_ix, PL_unitcheckav)
doesn't make much sense to me and is clearly (as advertized) a workaround
rather than a fix.

FWIW the test suite in 2.086000~dfsg-3 (i.e. without the PL_unitcheckav
workaround) passes for me on i386 if I first

 export CFLAGS="$(dpkg-buildflags --get CFLAGS) $(perl -MConfig -e 'print $Config{ccflags}')"

which expands to 
 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

and then call 'debian/rules build' normally.

Marpa::R2::Build_Me seems to append its stuff to $Config{ccflags} like it
should. I think the bug is in the Debian cdbs logic, which ends up calling
 perl Build.PL  --installdirs vendor --config ccflags="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall"

which probably makes Module::Build override everything Marpa::R2::Build_Me
says about ccflags.

FWIW debhelper uses "optimize" instead of "ccflags" for this.
See /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm.

As an example, debhelper configures the libcss-minifier-xs-perl package like this:
    perl Build.PL --installdirs vendor --config "optimize=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2" --config "ld=cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"

which makes Module::Build preserve $Config{ccflags}, so it
compiles like this:
  cc -I/usr/lib/i386-linux-gnu/perl/5.20/CORE -DXS_VERSION="0.09" -DVERSION="0.09" -fPIC -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -o lib/CSS/Minifier/XS.o lib/CSS/Minifier/XS.c

So, this looks like a bug in /usr/share/cdbs/1/class/perl-build-vars.mk.
Cloning. AFAICS libmarpa-r2-perl and liblucy-perl are the only
Architecture:any (XS) packages in sid that are built with cdbs and
Module::Build, so it makes sense this hasn't been noticed before.
#763039 in liblucy-perl is probably related.

I'm surprised that the workaround in libmarpa-r2-perl helps. If I try to
build libcss-minifier-xs-perl without $Config{ccflags}, I see much worse
breakage.

Not sure what's the right thing to do for jessie, changing cdbs at
this point isn't very inviting. As all the libmarpa-r2-perl reverse
dependencies seem to work with the workaround according to Michael,
I guess this isn't release critical any more...
-- 
Niko Tyni   ntyni at debian.org