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