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

[Jeffrey Kegler]

> [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.]

I suspected something like this.  I do a lot of bit-twiddling in C.
While I sweat those details, I know that it's just not realistic to
exclude that I made some mistake in Marpa::R2 or Libmarpa that other
systems forgave, but s390 did not.

I did look at the flags and did think there was a very dangerous mix
of 32's and 64's in there. :-)

Marpa::R2/Libmarpa, before I upload any release, even a developer's
release, passes a large test suite on PPC and ARM, as well as i386, so
there is some degree of assurance that they are free of the most
glaring issues with architecture-dependency.

I spent the first decades of my career avoiding the predecessors of
the s390 architecture, which somehow makes me feel nostalgic about it,
and I'll be happy to see this port succeed. :-)

On Sun, Nov 23, 2014 at 12:47 PM, Niko Tyni <ntyni at debian.org> wrote:
> 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