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

Jeffrey Kegler jeffreykegler at jeffreykegler.com
Sun Nov 23 22:11:20 UTC 2014


Please ignore the s390 remarks.  I've confused the two on-going
Marpa::R2 bug threads. -- jeffrey

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



More information about the pkg-perl-maintainers mailing list